This is good advice. One caution about switching to Bundler is that it can also introduce a lot of change into the codebase at the same time you're trying to clean it up; managing both changes at once, and trying to isolate breakages to one or the other, can be tricky. Nonetheless you gain a lot in dependency documentation by making the move.
Laser (https://github.com/michaeledgar/laser) is a new Ruby static analysis tool that I caught a talk on at RubyConf. It might be worth a look for identifying dead code. You might want to at least try to put some high-level integration tests in place to ensure that none of your fixes break what's already there. (If this is a small app, maybe not necessary?) That said, tough to make the argument to invest in unit tests if you're just going to be cleaning everything up anyway. If Ruby had better tooling support for automated refactoring it might make more sense. Maybe it goes without saying, I would add "shifting complicated view logic into more testable helpers or classes" to your list. Brian On Wed, Oct 12, 2011 at 1:22 PM, Chris Berkhout <[email protected]> wrote: > 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. > > -- 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.
