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.
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.
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.
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)
I like Rails a lot and use it for my personal web-based projects. Rails (and Ruby in general) is (/are) great because of strong convention, as you mentioned.
But I would say that the danger is that you can break rules in bizarre unpredictable ways, which I've done myself and then gone WTF when going back to those projects years later.
It's also kind of annoying to set up and upgrade, lots of middleware to manage, but that's the case for almost every framework.
maerF0x0|3 years ago
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.
trebbble|3 years ago
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.
jack_riminton|3 years ago
tboyd47|3 years ago
tboyd47|3 years ago
Unfortunately many developers think they're more clever than the standards (and as a medium to display their cleverness, they find Ruby quite accommodating)
MiddleEndian|3 years ago
But I would say that the danger is that you can break rules in bizarre unpredictable ways, which I've done myself and then gone WTF when going back to those projects years later.
It's also kind of annoying to set up and upgrade, lots of middleware to manage, but that's the case for almost every framework.