Posts Tagged ‘Book Club’
This week at book club we continued the three-chapter theme, taking on chapters 17, 18 and 19 of Working Effectively With Legacy Code. Chapter 17 is the most lengthy of the three and we spent almost all of our time discussing that one.
Chapter 17: My Application Has No Structure
In this chapter Feathers discusses why code bases degrade. He says that “They (applications) might have started out with a well-thought-out architecture, but over the years, under schedule pressure, they can get to the point where nobody really understands their complete structure.” He gives three possible reasons why a team may be unaware of this happening:
- The system is so complex that it takes a long time to get the big picture
- The system can be so complex that there is no big picture
- The team is in a very reactive mode, dealing with emergency after emergency so much that they lose sight of the big picture
Feathers details some suggestions for how to communicate the intent of a system including ‘Telling the Story of the System’, a process where “One person starts off by asking the other ‘What is the architecture of the system?’ Then the other person tries to explain the architecture of the system using only a few concepts.” This is useful because “Often when we force ourselves to communicate a very simple view of the system, we can find new abstractions.”
- I think all of us have used this technique when first coming to a project to try and get an understanding of the system. I usually have this type of conversation with each pair for the first couple of weeks on a project.
- Ahrum said that in his experience developers find it very difficult to explain a system simply because we generally go into too much detail. Giving information about logging and security are examples including too much noise in the explanation.
- Tom said that it’s important to speak with everyone on the project, not just the architect. He finds that architects generally focus too much on application layering.
- I think this technique is related to Dan’s idea of having a project shaman.
Feathers also discussed Naked CRC. This is a lightweight version of CRC where there is no writing on the cards. “The person describing he system uses a set of blank index cards and lays them down on a table one by one. He or she can move the cards, point at them, or do whatever else is needed to convey the typical objects in the system and how they interact”. I’ve never used this approach before but Anita and I both said that we would like to try it because we think we’re visual learners. Tom suggested that combining the cards and a whiteboard could also be useful, especially to show interactions between components.
We also spent some time discussing other techniques for getting the big picture of an application, especially when encountering it for the first time:
- Reading the code can be a good way to spot major concepts or the lack of them.
- Raphael said that it’s useful to listen to the language that people use to describe the system and to compare that to the concepts in the code. Sarah and Mark both recently posted on this.
- Tom said that he likes to make lots of mindmaps when he first goes onto a new project. He said he generally likes to observe for about a month before he attempts any large refactorings.
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.