Working Effectively with Legacy Code - jmadison222/knowledge GitHub Wiki

| Home |


1. Action Items

  • Know that "legacy code" means unmaintainable code, regardless of age or business value.

  • Modularize your designs. Interlaced code breaks easily and is hard to test.

  • Test pervasively. This is the single biggest thing you can do—​but modularization must come first.

  • Retrofit in small increments until the code is highly maintainable.


2. Rationale

Legacy code is not about age; your team can literally be writing legacy code in real time. It is not about business value; some terrible code can have high business value. It is about maintainability. Maintainability comes from three major things.

The first is modularity. Large blocks of functionality are harder to understand, test, and maintain. Modularized codes can, in particular, be tested well.

Second is pervasive testing. This is the core of the argument. Code that can be thoroughly and easily tested can be maintained indefinitely. Pervasive testing is most easily done on well modularized code.

Third is doing the previous two in very small increments. Legacy systems are easy to break. Changing code is a major culprit for breaking them. But you have to change the code to make things modular and testable. It’s a vicious circle, so make the changes tiny and only do the next one when the current one is stable. (And yes, you have to change code to make it testable. Tests are not external. Good testing needs hooks into the core code).

That’s it! Other commentators summarize to more themes than I do. And the book goes into great detail on the mechanics. But I like short lists with items that have short definitions. Modularize and test, and do it in baby steps—​that is the 80/20 core of great software engineering in general, but in maintaining legacy code in particular.

The topic is dry, so the book is dry. For most people, these summarizes are enough:

Those with serious legacy code needs might benefit form the book, but for most, just read the two summaries and figure it out for yourself from there.


3. Source

The rationale section above is taken from the following book:

c6f4712f 6dda 4f0c 9e03 3a15df66d3d2


⚠️ **GitHub.com Fallback** ⚠️