This version of Vestibule is read only. It represents an archive of the community effort to produce content for Ruby Manor 4.

Legacy Rails Apps: A Collection of Antipatterns

updated over 4 years ago; latest suggestion over 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.

Suggestions

  • A6748d9bae5729f00802fd85fc01fd44 Stuart Eccles suggests over 4 years ago

    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.

  • 6597b956887bfa6066bd08be263a08ca Joel Chippindale suggests over 4 years ago

    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

  • 9aad27c9b22345c079622758970e24ff Robert Chatley suggests over 4 years ago

    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?

  • 2abf5beb51d5d66211d525a72c5cb39d Paul Battley suggests over 4 years ago

    I'd also be interested in lessons in how to make future projects less "legacy" in future.

  • The proposal author responds over 4 years ago

    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.

  • B68ce3695bb8dc29b9f9cb0dc0b721a5 Murray Steele suggests over 4 years ago

    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.

  • Acd62030df551952268e84c8fff26a5b James Adam suggests over 4 years ago

    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.