Hacker News new | ask | show | jobs
by nerdwaller 2922 days ago
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, ...)

2 comments

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.
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.

I think linters and IDEs will help with that.i already see big improvements in js linters
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.