I worked on a similar project earlier this year. Some things I did and would recommend:
- Make sure the app can run with a schema load and seeds only (ie. not dependent on production data). - Remove anything from the repository that's obviously unused. - Add bundler for managing gems. `gem list` on the production server may be the only record of specific gem versions used. Do that to get clues, then start with bundler so you have a Gemfile.lock file. http://gembundler.com/rails23.html - Switch any plugins to gems (may be personal preference, but if I need things vendored, I'd still want to do it via bundler). Upgrade or switched gems to actively maintained versions where possible. - If there are any tests, get them passing or remove them. I had 4 test suites from different times, using different tools. I merged them into one rspec suite. - Improve view templates by using a beautifier (e.g. https://github.com/threedaymonk/htmlbeautifier/) and extracting logic that should be in models. - Refactor names to be consistent throughout the app and consistent with end user terminology. - Upgrade to Rails 3. Do do this if you're planning any future for this app. It wasn't as tough as I expected. Ryan Bigg's article helped me: http://ryanbigg.com/2010/11/the-rails-3-upgrade/ If you haven't read a book on refactoring, I recommend: http://www.goodreads.com/book/show/3892685-refactoring Cheers, Chris On Wed, Oct 12, 2011 at 7:06 AM, Michael Pearson <[email protected]> wrote: > Hi, > We have a large Rails 2.3.x codebase, mostly written by a developer without > prior experience with Rails who has since left the company. > What I'm trying to do is put together a list of things to look out for and > continually improve, specific to Rails 2.x. > Most of the below seems to be about removing code duplication and fixing Law > of Demeter violations: > > use flay to identify code duplication > remove all instances of raw SQL outside of app/models by using model methods > and named scopes > ensure controllers aren't calling other controllers directly > create crudify-like base class for controllers generated using > script/generate scaffold > parse logs to identify unused controllers > > Notably not on this list is unit or integration testing. The code is not at > the point where this can be performed effectively. > Any Rails-istas have any tips for other things to look out for? This list is > intended as things to fix while we're working on bugfixes or new features > rather than trying to perform a ground-up rewrite. > Also, are there any tools that can replay a log and perform code coverage > analysis in Ruby? Has anybody adapted rspec's coverage tools to do this? > -- > Michael Pearson > The Bon Scotts; http://www.thebonscotts.com > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
