More on this book
Community
Kindle Notes & Highlights
So, my overall advice on performance with refactoring is: Most of the time you should ignore it. If your refactoring introduces performance slow-downs, finish refactoring first and do performance tuning afterwards.
we can go beyond taste and say that the true test of good code is how easy it is to change it.
Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.
If someone says their code was broken for a couple of days while they are refactoring, you can be pretty sure they were not refactoring.
statement Kent Beck often makes about himself: “I’m not a great programmer; I’m just a good programmer with great habits.”
Done well, my code base turns into a platform for building new features for its domain.
The whole purpose of refactoring is to make us program faster, producing more value with less effort.
My colleague Pramod Sadalage developed an approach to evolutionary database design [mf-evodb] and database refactoring [Ambler & Sadalage] that is now widely used.
The third approach to performance improvement takes advantage of this 90-percent statistic. In this approach, I build my program in a well-factored manner without paying attention to performance until I begin a deliberate performance optimization exercise.
I’ve found that refactoring helps me write fast software. It slows the software in the short term while I’m refactoring, but makes it easier to tune during optimization. I end up well ahead.
A technology that’s currently gaining momentum is Language Servers [langserver]: software that will form a syntax tree and present an API to text editors.
Bill Wake’s Refactoring Workbook [Wake] that contains many exercises to practice refactoring.
Refactoring to Patterns [Kerievsky], which looks at the most valuable patterns from the hugely influential “Gang of Four” book [gof] and shows how to use refactoring to evolve towards them.
Refactoring Databases [Ambler & Sadalage] (by Scott Ambler and Pramod Sadalage) and Refactoring HTML [Harold] (by Elliotte Rusty Harold).
Michael Feathers’s Working Effectively with Legacy Code [Feathers], which is primarily a book about how to think about refactoring an older codebase with poor test coverage.
“If it stinks, change it.” — Grandma Beck, discussing child-rearing philosophy
Puzzling over some text to understand what’s going on is a great thing if you’re reading a detective novel, but not when you’re reading code.
In our experience, the programs that live best and longest are those with short functions.
A heuristic we follow is that whenever we feel the need to comment something, we write a function instead. Such a function contains the code that we wanted to comment but is named after the intention of the code rather than the way it works.
We structure our software to make change easier; after all, software is meant to be soft.
The fundamental rule of thumb is to put things together that change together.
Some people consider any method chain to be a terrible thing. We are known for our calm, reasoned moderation. Well, at least in this case we are.
As with a class with too many instance variables, a class with too much code is a prime breeding ground for duplicated code, chaos, and death.
comments are often used as a deodorant.
I’m a pretty lazy person and am prepared to work quite hard in order to avoid work.
Writing the test also concentrates me on the interface rather than the implementation
I’ve been even happier to see the change in attitudes to testing. Previously seen as the responsibility of a separate (and inferior) group, testing is now increasingly a first-class concern of any decent software developer. Architectures often are, rightly, judged on their testability.
Some people advocate using test coverage [mf-tc] as a measure, but test coverage analysis is only good for identifying untested areas of the code, not for assessing the quality of a test suite.
The best measure for a good enough test suite is subjective: How confident are you that if someone introduces a defect into the code, some test will fail?
[Forsgren et al.] Nicole Forsgren, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press, 2018. ISBN 1942788339.
