Image may be NSFW.
Clik here to view.
Last Friday I got to spend another day with the dev team at Protime, running a coderetreat on dealing with legacy code this time. I don’t call it a legacycoderetreat here because it was really different from what J.B. showed us last year. Since I was working with a team that already had their end-to-end tests set up, we didn’t have the need to go into a golden master session. I wanted to relate the different refactoring techniques to the ideas and principles we discussed during the ‘normal’ coderetreat earlier.
After receiving the codebase I went on my quest to find possibilities for refactoring. It’s something I really like doing. You can call me a weirdo, but I really enjoy looking for refactoring opportunities and cleaning it up. I could probably spend half my time just cleaning up code and enjoying myself. This was of course not the goal for this quest. I was looking for typical code smells, things that could be improved by using a handful of handy practices.
After a while digging through Martin Fowler’s refactorings archive I came up with a handful of useful techniques that I could also relate to the four elements of simple design. The tips we got to practice during the sessions ranged from inverting conditionals through the use of guard clauses over consolidating conditionals through extracting a conditional method for it right down into extracting classes that will hold database independent behavior which was currently implemented in the model classes of their application.
Adi sent me a link to the closing keynote Corey Haines gave at the arrrcamp 2011 here in Belgium. During this keynote he talks about extracting your real business logic, which is completely independent of your database, from your active record models and into separate modules or classes. We spent a session on that topic, trying to extract behavior like that and speeding up the real unit test suite that we can use during our TDD cycle. Everyone who has talked to me about software design and architecture knows that the single responsibility principle is one of my favorite topics. Extracting the real behavior from the active record models, which are just the simple data structures, sounded like common sense.
Just today I received a message from Christiaan, one of the guys that was in the dev team last week. He found a closing keynote by Uncle Bob talking about designing your architecture in a way that will decouple it completely from all external dependencies like your database (active record) or your delivery mechanism (rails – mvc). All these things have inspired me to take up this study of legacy systems and how to really decouple them into a working architecture again.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
