I bought this book at a conference I attended last year. The place I was working had a serious legacy code base and was in desperate need of refactoring. Unfortunately, I didn’t get too far into the book before I realized the development group there was no where near mature enough to accept this sort of change. The founder continually pestered me to stop spending so much time testing and just get software out. He honestly didn’t (doesn’t) understand the purpose of automated tests, much less any realistic quality process. Needless to say we didn’t get along too well and I left not long afterwards. My current employer also has a large legacy code base, but fortunately the organization is much more willing to embrace change. So, I picked this back up again as it seems now seems useful.
Working Effectively with Legacy Code is mainly a patterns book. It covers both how to get unruly code into an automated test harness and once there, how to refactor it. In general, refactoring is better covered in Martin Fowler’s Refactoring, but as the title suggests, many of the patterns here deal specifically with situations commonly found in legacy code: “Dependencies on Libraries Are Killing Me,” “My Application Has No Structure,” and “I Don’t Understand the Code Well Enough to Change It” are three chapter titles. As with most pattern books, it all seems very straightforward once you read it but before reading it you’d be hard-pressed to succinctly explain the techniques.
Many thoughts expressed here I wholeheartedly agree with. “Safety first. After the tests are in place, you can make the code much cleaner.” The echo of test driven development, this idea is essential to confidently modifying existing code. Without solid tests, refactoring is a guessing game at best. Feathers also recommends avoiding “big bulky unit tests that take forever to run.” In fact, he goes as far as saying that any test that takes 1/10th of a second is considered slow. In his mind, if it talks to a database, communicates across a network, or touches the file system, it isn’t a unit test. While I think that is taking things a bit too far, the sentiment is admirable.
Another interesting quote: “Architecture is too important to be left exclusively to a few people. It’s fine to have an architect, but the key way to keep an architecture intact is to make sure that everyone on the team knows what it is and has a stake in it.” This is exactly right. A good software architect is responsible for the big picture, not for the nitty-gritty details. If you are on a team where the architect does all the design and expects the developers simply to code up his designs, start looking for a new job!
One last message: when developing software, always keep your focus; do only one thing at a time. If you bite off too much at once, you end up thrashing. While especially true for refactoring untested or legacy code, this is very good advice for any development project.
Changing code is great.
No comments:
Post a Comment