Working Effectively with Legacy Code

This article are just my notes from the book. Finally the one that covers my daily job. Books like Refactoring (by Martin Fowler) or Clean Code (by Robert Martin) are all fine, but also a bit academical. I have never professionally encounter a clean code. The code is never enough test-covered these days (here in Prague at least). And this book is the one that deals with non-tested huge code-base or a legacy code for short.

The Mechanics of Change

Of course we all read the Refactoring book, which is almost a bible among the developers. So we know that the change is ubiquitous and we can preserve quality of code over time only by refactoring. However there is a catch - code must be tested. That is why we need to put it under the test first.

Here is algorithm of change for legacy code:
  1. Identify change points. Obviously you have to find the place for your changes on your own. Every programmer must have done this a million times, so there is nothing new to you here.
  2. Find test points. Determine what methods to test. You are trying to protect yourself from introducing bugs.
  3. Break dependencies. Every class has dependencies on other classes. You must break these to really unit test your class/method. There are many techniques, we'll talk about them later. Just remember - try to minimize your impact on existing code because it is not tested yet.
  4. Write tests. If you don't know how, I recommend the TDD book (by Kent Beck).
  5. Make changes and refactor. Well, this is the whole point. This book is trying to enable us to do this. This book recommends TDD, but you are free to use your favourite technique.
Changing software

One important question is: What method should I test? An answer to this question could be pretty straightforward if you have to make only a small change. You can check what data it will change and test methods that depend on that data and return something. If you have more classes to change, you should find closest interception point, that you will put under test to make sure you don't break anything.

Another interesting topic are the Characterization tests. These are classic unit tests, but you are not trying to test for right behavior. You are trying to test for an actual behavior at the moment. So when you will make your refactoring in the future, you won't spoil anything (even bugs must stay).

Dependency-Breaking Techniques

Mr. Feathers presents us techniques you can use to break the class dependencies, so you can put your class / method under the test. These techniques work as refactorings (they preserve behaviour), but unlike refactorings they do not depend on existence of tests (they are safe enough, not changing existing code so much). Some of them are:
  • Extract and Override Call. Sometimes you have only small pieces of code in a class calling other static class. In this scenario, you can extract these calls to a separate method (Extract Method refactoring works fine in many IDEs). Then in test environment, you subclass this class and override this new method with fake behavior.
  • Extract Interface. This is the way to make fake implementations. You just extract original interface and then have both production and test class implement it.
  • Subclass and Override Method. One of the basic techniques. You create a sub-class in the test environment that overrides some behavior of the original class. Then you inject (with setter) a fake object to break a dependency.
  • Adapt parameter. Sometimes you don't need the whole interface of production code in your to-be-tested method. You just need smaller portion of it. So you can extract just what you need and use this new interface as a parameter instead of original production code class.
  • Encapsulate Global References. This is one of the refactorings how to deal with global references (static methods). You can encapsulate them into the brand new class. Then you replace their original use of course.
  • Expose static method. Suppose you have to change part of the method. You can always extract that part into the static method (which will use only its parameters). Then you can expose (make public) this method and test it.
Conclusion

I think the most important motto of this book is - don't apply the 'code & pray' technique when modifying a legacy code. Code safely by unit testing first.

Comments

Post a Comment

Popular posts from this blog

Notes about the Clean Architecture book

The first look into the contents of the book was a bit scary. Some of these things were already explained in Robert Martin's previous books. Then I found out they are explained from a different (software architect's) perspective. Overall, I liked this book better than Clean Coder, but it was less useful for me than Clean Code book of the same author. Part I - Introduction The foreword contained two useful antipatterns: Too authoritative and rigid architecture. Speculative generality in software architecture. The main point of the preface is that not much changed for the last 50 years in software architecture. The rules of software architecture are the same regardless of any variable (time, type of project, ...). When you get the architecture of the software right, you magically don't need horde of programmers maintaining it. Chapter 1 - What is Design and Architecture? There is no difference between software design and architecture. There is a continuum of
Read more

Notes about the Building Microservices

These are notes for my future self about Sam Newman's book, Building Microservices 2nd edition.  Preface Microservices are an approach to distributed applications that use finely-grained services and change, deploy and release them independently. Microservices have become the default go-to architecture when designing system, which Newman finds hard to justify #surprised and want to share his view on why. Foundation Chapter 1 - What are Microservices? Microservices are independently releasable services modeled around a business domain . They are kind of SOA, but the one which is opinionated about how service boundaries should be drawn and where independent deployability is the key. Microservices should implement information hiding and expose their API in some way, e.g. via REST/JSON API or by emitting events. They should have their own database schema. To highlight that the services are as independent as possible, Newman draws them as hexagons, a homage to Alistair Cockburn's H
Read more

Notes about A Philosophy of Software Design

My notes about the book by John Ousterhout. It is quite a short book. Originally I made a mistake of reading just the Conclusions of the chapters but there is a lot of contents not in the Conclusions. After really reading the whole book, I started to like the Red Flags and other small pieces of hints. Chapter 2 - The Nature of Complexity Complexity is anything related to the structure of a system that makes it hard to understand or modify. Isolating complexity in a place where it will almost never be seen or touched is almost as good as removing it. There are many symptoms of complexity: Change amplification - when change requires modification in many places.  Cognitive load - how much a developer must know in order to make a change. Sometimes more code is simpler than less code because of cognitive load. Unknown unknowns - it is not obvious which places should be modified or what knowledge the developer must have to make a change. Complexity is caused by 2 things - dependencies and o
Read more