Legacy Rails Apps: A Collection of Antipatterns
updated about 4 years ago; latest suggestion about 4 years ago
There's more to life than Models, Views, and Controllers. Organising large Rails projects is more of an art than a science. Changing company culture leads to half-arsed attempts at applying different principles to your codebase.
Using examples from one of our legacy codebases, I'll go through some code smells and show some ways to clean it up. There is more than one way to write clean code in Ruby, so where possible I'll try to show different solutions.
Will include obligatory taking the piss out of a legacy codebase.
This is just a rough idea, so if you have suggestions of where it should go, I'd love to hear them.
I'd like to second Paul. Refactoring is a cat in a bath exercise but I'd like to stay out of the bath.
It seems that nearly everything we do now becomes legacy so fast, i'm seriously doubting Rails patterns are enough to be applying from day one to make a good application.
I would love to know other ways to do things from day one, especially ideas beyond things such as presenter, ActiveSupport::Concern, etc.
If you wanted an old open source rails project to use as an example then the rubygems app might be worth a look, although I have done any spelunking around the code to see what it's general state is like
I'm interested in the tipping point when a Rails app goes from a fast-to-work-with app to a legacy ball of mud (or similar). Any pointers on when/how that happens and when/how to take action?
I'd also be interested in lessons in how to make future projects less "legacy" in future.
I agree that a big-picture on coping with legacy apps would be more useful, and interesting. I was planning on showing a few examples of issues, and how I chose to fix them (maybe mention a few alternatives). Then talk about how the problem arose and try to generalise the solution.
I do have a specific codebase to pull examples from, but it's not open source. Any suggestions for an open-source codebase to use would be excellent.
After this talk, would I walk away with a set of rules and tips for fixing specific legacy code problems, or would it give me a framework for tackling any legacy app? In either case the talk would look about 80% the same. I think that stepping back in the last few slides to look at the big picture of coping with legacy apps would really make this talk something much more useful.
Do you have a specific codebase in mind? Is it already open-source? If this proposal was selected, I think it might be useful/interesting/worthwhile to share the code ahead of time, and encourage people to try out some of their own refactorings first; that might make the talk more engaging when you discuss your own choices.