Hi, I would highly recommend reading "Working with Legacy Code" by Michael Feathers. It's full of advice on how to lock down legacy code and save it gradually. The examples are mostly (all?) in Java, so the actual steps would be different, but I think it could give you an idea of how/where to start.
Katrina On Sat, Dec 11, 2010 at 6:47 PM, Shea Levy <s...@shealevy.com> wrote: > Hi all, > > I was recently brought onto a Rails 2.2.3 project which was itself an > emergency rescue of a spaghetti-coded PHP project (complete with hard-coded > SQL statements!). Due to the fact that the code was already in production > and has required fairly constant maintenance and feature additions, the dev > who switched everything over to Rails hasn't written a single test. The > eventual goal, the achievement of which is one of my primary > responsibilities on the project, is to have the project be migrated to Rails > 3, fully spec'd at all levels and documented at the top level with Cucumber > features, matching Rails conventions (e.g. the database table for the Shop > model is currently 'shops_master' and will eventually be 'shops') and with > all vestiges of the original project completely removed (there's still some > PHP code running on the production site). My question is: what's the best > approach to get from here to there? Is it possible to do this gradually > while development continues on the current project, or is a total refresh > going to be necessary? I'd much prefer a gradual approach because the other > dev on the project is working full-time on adding features to and > maintaining the current site and all of my responsibilities outside of the > migration will be focused on adding features to the current site, so if I > were to do a complete refresh any work from here on out would be completely > duplicated. Additionally, the other dev on the project (who has much more > general coding experience than I do) won't be able to spare time to help me > out with problems on a refresh the way he would if any gradual changes were > implemented on the current project. The only problem with the gradual > approach is that I have no idea how to actually do it! Do I start with > unit-tests of the already-existing code and work my way out to features, or > do I start with features describing things already implemented and work my > way in? Do I try to convince the other dev to start outside-in with all new > features now, or do I wait until I've done more with what's already there? > Are there any good resources out there for tasks like this? Also, if a > refresh IS necessary: what's the best way to go about replicating the > functionality of an existing project? > > tl;dr: Is it possible to save a test-free project via gradual steps, or is a > complete refresh necessary? If the former, how do I go about doing that? If > the latter, how do I do it in a way that keeps overall functionality of the > resulting project the same as the original? > > Cheers, > Shea Levy > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
