[artursapek]

I spent 3 years working on a Rails app and it was enough to make me swear off Rails for the rest of my life. I think the Rails dev community has good intentions, and the design of Rails is actually pretty nice. The problem in my opinion is more with Ruby, and human laziness. Ruby lets programmers do absolutely anything they can think of no matter how unexpected or un-intuitive it will be to their colleagues. Combined with the rigid conventions of Rails' design, this inevitably leads to a maintenance disaster with people, like you say, getting too creative.

Refactoring a large Ruby on Rails codebase is basically impossible. There's no compiler to help you along; hell the code is evaluated lazily. So instead of refactoring, people monkey-patch their problems away. It's horrible, really really horrible.

I'm now getting flashbacks to trying to understand how files get loaded in that codebase... I need a drink

[joelbluminator]

I don't completely get this sentiment. Is refactoring a big java program easy? Yes, you will get nice hints from the IDE, but who knows how many things you screwed in the process of refactoring that the compiler isn't telling you about? Especially when it's not your code, when the person who wrote it isn't there, when you're not 100% what the code is actually doing, when it's undocumented and the intent isn't clear etc etc. Or worse when there aren't any tests which I'm sure happens a lot in java land. Why would this be specific to Rails? You're making it sound as if the twitter team can rewrite their app in 2 days because of 'compiler'. Big complex projects are big and complex. In Java / C# / Scala they're even bigger because of types, interfaces, traits and other kind of verbosity. It makes it harder to wrap your mind around the application in the first place.

[nerdwaller]

It seems like you’re taking this a bit further than the parent comment said - e.g. there’s no claim that any major piece of software can be refactored that quickly, however the general process can be made simpler and safer with decent static tooling.

As a concrete example on a small scale of something common such as renaming a model field name. Given that ActiveRecord reflects the database and generates the methods dynamically there’s pretty much no good way to refactor that field easily. It requires a lot of manual searching/filtering to find possible usages and then time on that to ensure it’s not a shared name on a different object type. From what I’ve seen in many code bases it ends up manifesting as `delegate` usage and often just expands the API exposed by the model.

Compare that to something compiled, or even something like python that doesn’t encourage meta too much, and you can pretty much find all symbol usages with whatever intellisense engine you prefer (ctags, JetBrains, jedi, ...)

[joelbluminator]

I agree static analysis can help. Specifically for changing column names it just doesnt really happen that often in most projects I worked on...so I never really thought it to be a big deal.

[StaticRedux]

Then you're lucky. I specialize in refactoring and reorganizing extremely messy and large / complex applications. And Rails is my fucking nightmare. Especially when untangling ActiveRecord callbacks, fat controllers, convention over configuration, magic method, and database changes.

I would give a kidney to have static compilation in rails when refactoring.

[joelbluminator]

I think linters and IDEs will help with that.i already see big improvements in js linters

[nerdwaller]

That goes to my point, rails doesn't have the symbols in code for the editor to use to refactor because they are added at runtime dynamically when ActiveRecord reflects the database. You can have a full model that just has `class User < ActiveRecord::Base; end` that has 15 fields on it, none of which are in the code.