Working Effectively with Legacy Code (Robert C. Martin Series)
by Michael Feathers
This was a pretty sweet read, but I think I would have gained more value from it if I were currently working on a legacy code base. (Please Don’t read that as…
“I want to work on a legacy code base.”)
This book is loaded with a catalog of refactorings to improve the design of existing code and get it under a test harness. Below is a list of some of the quotes from the book that I stuck out for me…
The Legacy Code Change Algorithm
* Identify change points.
* Find test points.
* Break dependencies
* Write tests.
* Make changes and refactor.
Over time, tested areas of the code base surface like islands rising out of the ocean.
“Mock objects are fakes that perform assertions internally.”
”…it is better to depend on interfaces or abstract classes than it is to depend on concrete classes. When you depend on less volatile things, you minimize the chance that particular changes will trigger massive recompilation.”
“The heuristics for identifying responsibilities can really help you dig in and find new abstractions in old classes, but they are just tricks. The way to really get better at identification is to read more. Read books about design patterns. More important, read other people’s code. Look at open-source projects, and just take some time to browse and see how other people do things. Pay attention to how classes are named and the correspondence between class names and the names of methods. Over time, you’ll get better at identifying hidden responsibilities, and you’ll just start to see them when you browse unfamiliar code.”
”… when I first thought about becoming a programmer, I was really captivated by stories about super-smart programmers, those guys and gals who could keep the state of an entire system in their heads, write correct code on the fly, and know immediately whether some change was right or wrong…
Holding on to a lot of state mentally can be useful, but it doesn’t really make us better at decision-making. At this point in my career, I think I’m a much better programmer than I used to be, even though I know less about the details of each language I work in.”
“When interfaces were first introduced in languages, some people started naming interfaces by placing and “I” before the name of the class they were gleaned from… The advantage to this sort of naming is that you don’t really have to think about the name when you the extraction. The disadvantage is that you end up with a lot of code that has to know whether it is dealing with an interface. Ideally, it shouldn’t care one way or another.”