5 ms·

The codebase I'm working on now is what I consider an exemplary Ruby on Rails project. It is 14 years old and still going strong. It is structured exactly like

The codebase I'm working on now is what I consider an exemplary Ruby on Rails project. It is 14 years old and still going strong. It is structured exactly like you'd expect a Rails project to be structured. The gems the authors chosen have been reliable so far with few exceptions. We regularly step into sections of code that are 5 or even 10 years old, and modify/extend them with no issue. Even brand new programmers (fresh out of boot camp) find it easy to work with. It is a success by all standards of software engineering.

kinduff 4y ago
Same here. But the one I'm using is 7 years old. Very nice code, some opportunities here and there, of course. I always mention this when I'm hiring: our codebase is "old", but the code is actually well written and tested. I've seen worse code in projects that are just a couple of months old.
shinzui 4y ago
A traditional rails structure does not age well. It must be a nightmare for any new hire to understand the domain and boundaries.
- ryanianian 4y ago
  Except that GP says it has aged well and isn't a nightmare.
jacobsenscott 4y ago
Yes. I'm working on an actively developed rails product that is close to 10 years old. All the stuff that just followed the "rails way" is still super easy to work with to this day. All the "experiments" (you find these in any old code base as developers and fads come and go) in "decoupling from rails" or whatever are extremely fragile and difficult to work with.
- bombcar 4y ago
  This applies to almost any programming language - things done "the standard way" will survive decently well (or have obvious migration paths) - things done "your own way" will be more fragile. Of course, languages vary on how much they have a "standard way" of doing things.
7373737373 4y ago
Same here. Knew nothing about Ruby before, the cleanliness and ease of deployment and database migrations/rollbacks with capistrano and rake made a great impression!
mbesto 4y ago
> It is 14 years old Curious - what version of Rails is it running on?
- tboyd47 4y ago
  When I joined, it was Rails 4. Since I've been there, we upgraded to 5 and are now about to start migrating to 6.
vinhboy 4y ago
I might get a lot of flame for this, but I would say this is probably true of most Rails project because Rails has a lot of great standards (opinions). I am not sure why people hate Rails, I love it exactly for this reason.
- maerF0x0 4y ago
  Personally I think the key is the code by convention mentality. This extends an idea used all throughout computing -- abstraction. The fact that you don't need to look at exactly how it's done, but can work with a generalized model with excellent results (albeit not necessarily perfectly optimal). IMO one kind of "bad code" is code where i need to know about >3 things/places to change 1 thing. Where features get splayed across N places instead of being able to live in their 1 spot + direct consumers.
- tboyd47 4y ago
  It's true of any Rails project that adheres to the great standards. :) Unfortunately many developers think they're more clever than the standards (and as a medium to display their cleverness, they find Ruby quite accommodating)
- trebbble 4y ago
  I've been in the guts of about five Rails codebases that were already in production, and they've all been very bad, and the badness difficult to overcome in part because of Rails and/or Ruby (which is why I hang some of the blame on Rails itself). IME Rails codebases are a few months with a mediocre team or a few bad choices away from becoming an absolute garbage fire, and all the magic in Rails is part of why even a little of that sort of activity does so much damage. Amazing for starting from scratch solo or with a very small team. Dangerous (mind: not necessarily bad, just dangerous) under basically all other scenarios, including ones that that sort of ideal situation might develop into. In particular, a great deal of discipline and excellent taste is required to maintain the kind of legibility and reliability other languages & frameworks can give you "for free". I expect a Rails project has the best hope of remaining good at a business that's got solid funding for an in-house team from day 1, and has good retention for that team. However, lots of startups or experimental ventures by larger firms experience a lot of thrashing and turnover in the early days, and often go through one or more periods of heavy outsourcing, while also being the kind of resource-constrained enterprise for which Rails is extremely tempting. Arguably Rails is still the right call for them, if it gets them to market fast, but those kinds of places consistently end up hit with slow, expensive, risky feature development just as they're starting to get traction, much earlier than the usual "eh, needing to replace this will be a good problem to have" phase, and part of that's because Rails falls apart so fast if you color outside the lines at all.

kinduff 4y ago

Same here. But the one I'm using is 7 years old. Very nice code, some opportunities here and there, of course. I always mention this when I'm hiring: our codebase is "old", but the code is actually well written and tested. I've seen worse code in projects that are just a couple of months old.

shinzui 4y ago

A traditional rails structure does not age well. It must be a nightmare for any new hire to understand the domain and boundaries.

ryanianian 4y ago
Except that GP says it has aged well and isn't a nightmare.

jacobsenscott 4y ago

Yes. I'm working on an actively developed rails product that is close to 10 years old. All the stuff that just followed the "rails way" is still super easy to work with to this day. All the "experiments" (you find these in any old code base as developers and fads come and go) in "decoupling from rails" or whatever are extremely fragile and difficult to work with.

bombcar 4y ago
This applies to almost any programming language - things done "the standard way" will survive decently well (or have obvious migration paths) - things done "your own way" will be more fragile. Of course, languages vary on how much they have a "standard way" of doing things.

7373737373 4y ago

Same here. Knew nothing about Ruby before, the cleanliness and ease of deployment and database migrations/rollbacks with capistrano and rake made a great impression!

mbesto 4y ago

> It is 14 years old Curious - what version of Rails is it running on?

tboyd47 4y ago
When I joined, it was Rails 4. Since I've been there, we upgraded to 5 and are now about to start migrating to 6.

vinhboy 4y ago

I might get a lot of flame for this, but I would say this is probably true of most Rails project because Rails has a lot of great standards (opinions). I am not sure why people hate Rails, I love it exactly for this reason.

maerF0x0 4y ago
Personally I think the key is the code by convention mentality. This extends an idea used all throughout computing -- abstraction. The fact that you don't need to look at exactly how it's done, but can work with a generalized model with excellent results (albeit not necessarily perfectly optimal). IMO one kind of "bad code" is code where i need to know about >3 things/places to change 1 thing. Where features get splayed across N places instead of being able to live in their 1 spot + direct consumers.
tboyd47 4y ago
It's true of any Rails project that adheres to the great standards. :) Unfortunately many developers think they're more clever than the standards (and as a medium to display their cleverness, they find Ruby quite accommodating)
trebbble 4y ago
I've been in the guts of about five Rails codebases that were already in production, and they've all been very bad, and the badness difficult to overcome in part because of Rails and/or Ruby (which is why I hang some of the blame on Rails itself). IME Rails codebases are a few months with a mediocre team or a few bad choices away from becoming an absolute garbage fire, and all the magic in Rails is part of why even a little of that sort of activity does so much damage. Amazing for starting from scratch solo or with a very small team. Dangerous (mind: not necessarily bad, just dangerous) under basically all other scenarios, including ones that that sort of ideal situation might develop into. In particular, a great deal of discipline and excellent taste is required to maintain the kind of legibility and reliability other languages & frameworks can give you "for free". I expect a Rails project has the best hope of remaining good at a business that's got solid funding for an in-house team from day 1, and has good retention for that team. However, lots of startups or experimental ventures by larger firms experience a lot of thrashing and turnover in the early days, and often go through one or more periods of heavy outsourcing, while also being the kind of resource-constrained enterprise for which Rails is extremely tempting. Arguably Rails is still the right call for them, if it gets them to market fast, but those kinds of places consistently end up hit with slow, expensive, risky feature development just as they're starting to get traction, much earlier than the usual "eh, needing to replace this will be a good problem to have" phase, and part of that's because Rails falls apart so fast if you color outside the lines at all.