Refactoring Improving the Design of Existing Code Book Review
As a code base changes its capabilities as most useful software does, we often find our abstraction boundaries shift.
- Martin Fowler
There are some annoyances in the print version. There is some bold pink font that is often blurry which causes a jarring effect when reading. Fowler will refer to topics he’s written about in the past, there are links to these articles in the bibliography. This is not so great in the print version. For example, Command Query Separation is dropped into a topic without a footnote. It would have been simple to provide footnotes with one sentence descriptions but he states in the bibliography that he decided against including definitions in the work. Personally, I would have preferred the footnotes but the point is minor. Command Query Separation if you were wondering, means any function that returns a value should not have observable side effects.
What is refactoring? The process of changing a software system in a way that does not alter the external behavior of the code yet improves its internal structures. Methodically improve structure without introducing bugs.
The first step in refactoring is a suite of tests.
When refactoring a large function, try to pick out parts that differ from the overall behavior.
Don’t worry about performance, it’s much easier to tune well-factored code. Refactor and then tune code if needed.
Treat data as immutable as possible, mutable data quickly becomes something rotten.
Always leave the codebase healthier then when you found it.
The true test of good code is how easy it is to change.
Refactoring is small steps, keeping the code in a working state and passing tests.
You don’t want a codebase that has lots of speculative flexibility. Instead you want one that responds rapidly to changing needs and is reliable.
Most of a programmers time is spent debugging. When you get a bug report, start by writing a unit test that exposes the bug.
Functions are the “joints” of our software system. The most important element of a joint is it’s name. There’s no right answer to a functions name or parameters but they will get better as the system evolves.
Naming things well is the heart of clear programming. The more widely a thing is used, the better it must be named. For dynamic languages its helpful to put the type in a name like aCustomer.
Long parameter list
Global Data - bad when mutable (Paracelsus’s maxim: the difference between a poison and something benign is the dose)
Mutable data - functional programming helps here.
Shotgun Surgery - when changes are all over the place and you have to make a lot of little edits
Speculative Generality - simplicity through experience rather than generality through guesswork.
Comments - often used as a deodorant for code smells. When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.
This is a strong book for programmers to read. From recommending that refactoring begins with a suite of tests, providing basic refactorings and then building on those to describe complex refactors. Fowler provides the pros and cons of each refactor, helping you become a better programmer one refactoring at a time. Highly recommended.