Book Club: Working Effectively With Legacy Code – Chapters 14, 15 and 16 (Michael Feathers)
Mark has returned to the UK so I’m continuing in his tradition of posting about the Thursday technical book club 🙂
This week we continued going through Working Effectively With Legacy Code, tackling an unprecedented 3 chapters:
Chapter 14: Dependencies on Libraries Are Killing Me
In this chapter Feathers describes how an overuse of direct calls to libraries can cause pain. He suggests that wrapping the API can create a nice seam for testing, so long as there are no constraints imposed by the use of language features such as final/sealed. As Matt pointed out this ties into the following chapter where Feathers discusses when the skinning and wrapping approach is most appropriate.
Chapter 15: My Application Is All API Calls
Feathers presents two approaches for improving the landscape when the application is all API calls:
1. Skin and Wrap the API
- Feathers introduced this idea in chapter 10.
- It is very useful for creating a separation layer from third party libraries.
- As Ahrum pointed out this can sometimes be a difficult task if there is a proliferation of library calls in the API.
- Matt also noted that this approach has more of a method level granularity, where as responsibility-based extraction has more of a class/object level granularity.
- We had some discussion about how far to take the skinning and wrapping – for example would you skin and wrap the I/O classes? I’m not entirely sure where I’d draw the line but this does seem like something that could be pushed to an unnecessary extreme.
2. Responsibility-Based Extraction
Feathers says that this approach is better suited to more complicated APIs. He writes:
“When we have a system that looks like nothing but API calls, it helps to imagine that it is one big object and then apply the responsibility-separation heuristics…. We might not be able to move toward a better design immediately, but just the act of identifying the responsibilities can make it easier to made better decisions as we move forward.”
Chapter 16: I Don’t Understand The Code Well Enough To Change It
In this chapter Feathers details some practices that can be used to get a better understanding of the code, including:
- Sketching out important things that you find in the code and connecting the concepts as you understand them.
- Effect sketching
- Printing the code out and marking it up in different colours to indicate different responsibilities. I’ve not done this before but it may be useful when doing responsibility-based extraction.
Feathers also says that you should delete unused code. As Anita quite rightly pointed out, deleting unused code extends beyond just commented out code and can be hard to detect. For example, there may be if-condition blocks that will never called in the application, but may be unit tested as though they are.