Working Effectively with Legacy Code

It's a known fact of life that code bases, if not actively nurtured, deteriorate with time. Maintaining, fixing bugs, extending, creating new features; all exert forces that push a design beyond its original intended boundaries, breaking the envelope of its original frame. Not long after its first release (sometimes, even before it), there's not even a trace of design, there's no conceptual integrity; duplication and needless complexity abound. Understanding and changing such systems is very difficult, technical debt never seems to decline. No position is more dreaded than that of the maintenance programmer. It's certainly not fun to work in these big balls of mud. Debugging sessions can take days, every time a change is required, there's fear that some unrelated functionality might suddenly break.

Working Effectively with Legacy Code

In the book Working Effectively with Legacy Code, author Michael Feathers gives wonderful advice and practical, to-the-point techniques to deal with these quagmires of rotting code. The book revolves around gradual improvements of the code, by covering it with unit tests, breaking its internal dependencies and slowly bringing it under control. Most of the examples use widespread object-oriented, statically-typed languages, like Java and C++, but its plethora of refactorings and heuristics are broadly applicable to a wide range of programming languages, even with different paradigms. The book defines legacy code as "code without tests", which brings about the shocking realization that many people are writing it right now.

Dependency-breaking techniques are at its heart. Their goal is to decouple areas of the code, so that they can be covered with tests. The tests are the instruments that allow changes to be made, and new capabilities to be added, with reassuring feedback that the code still does what it's supposed to do. It's a slow but rewarding process; where each step gives more understanding, and more courage to change the code. This is not an easy task, but the book has a way of making it an interesting one.

I particularly liked the emphasis on unit tests, and the fact that there's no debugging techniques section. Although a debugging session is a necessary activity at times, its results are not automatically captured; most of its goals should instead be described as unit tests. I find myself using less and less debugging sessions the more I write tests.

This is a timeless software book, that should have a place in the bookshelf of every software professional. It's specially important in large organizations, with big and unwieldy projects, but it's also applicable in small and medium development shops, if only to prevent the code from becoming legacy.

Comments

Post a Comment

Popular posts from this blog

The Acyclic Visitor Pattern

Knock knock The visitor design pattern is a way to add new operations to a hierarchy of classes without having to change the hierarchy itself. For example, with a simple hierarchy of fruits, you can have an IFruitVisitor interface that operates on the different classes in the hierarchy (in C#): interface IFruitVisitor { void Visit(Apple apple); void Visit(Grape grape); } The hierarchy classes then accept the visitor and fulfil the double-dispatching necessary to call the right Visit method: abstract class Fruit { public abstract void Accept(IFruitVisitor visitor); } class Apple : Fruit { public override void Accept(IFruitVisitor visitor) { visitor.Visit(this); } } class Grape : Fruit { public int NumberOfGrapes { get; set; } public override void Accept(IFruitVisitor visitor) { visitor.Visit(this); } } Note how each Accept method looks the same but is actually dispatching to a different method in the visitor ( Visit(Apple) and Visit(Grape) ). ...
Read more

C# Mixins With State

With the C# quasi-mixin pattern , one of the biggest limitations is that the mixins can't introduce state to a class. An alternative was for the mixin interface to require the composing classes to implement a property that the mixin would use as its own, as demonstrated in this example . In the .NET Framework 4.0, the ConditionalWeakTable<TKey, TValue> class can be used to associate arbitrary state to any instance. It's thread safe and it keeps a dictionary of weak references from the target instance to its associated state. If a target instance has no references outside the conditional weak table, then it can be reclaimed by the garbage collector. When that happens, its entry in the table is removed. This makes it possible for a mixin-like class to maintain state for the instances it extends. Let's look at a mixin for a message container: public enum MessageType { Error, Warning, Info } public class Message { public readonly MessageType Type;...
Read more

Some OO Design

"The critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology." - Craig Larman I've recently found the following interview question on stackoverflow : Basic sales tax is applicable at a rate of 10% on all goods, except books, food, and medical products that are exempt. Import duty is an additional sales tax applicable on all imported goods at a rate of 5%, with no exemptions. When I purchase items I receive a receipt which lists the name of all the items and their price (including tax), finishing with the total cost of the items, and the total amounts of sales taxes paid. The rounding rules for sales tax are that for a tax rate of n%, a shelf price of p contains (np/100 rounded up to the nearest 0.05) amount of sales tax. This is a very familiar example that can be used as a really good gauge of various software development skills. There are many different ways to solve this problem. ...
Read more