"Over time, the code will be modified, and the integrity of the system – its structure according to that design – gradually fades. The code slowly sinks from engineering to hacking." (Preface p.xiv)
If the code works and doesn't ever need to change, it's perfectly fine to leave it alone. It would be nice to improve it, but unless someone needs to understand it, it isn't causing any real harm. (Chapter 1 p.5)
That conclusion is a piece of the insight about the code. This understanding is in my head — a notoriously volatile form of storage. (Chapter 1 p.7)
Sometimes a refactoring will have a significant performance implication. Even them, I usually go ahead and do it, because it's much easier to tune the performance of well-factored code. (Chapter 1 p.20)
I prefer to treat data as immutable as much as I can — mutable state quickly becomes something rotten. (Chapter 1 p.27)
- Tests are foundational to refactoring. Refactoring without tests compromises the productivity of the refactor and may create a negative impression of refactoring for everyone involved. This includes the engineer who is now introducing bugs as well as product stakeholders that associate refactors with bugs.
- Consider sacrificing perceived performance for readability. Humans are awful at understanding true performance bottlenecks by just reading code. Engineers should focus on writing code that is easily understood so in the event that profiling shows that there are performance bottlenecks, the code can be easily changed.
- Consider introducing Phases into the code. Rather than interleaving the building and distilling of input into what needs to be created, input could be built into a cohesive collection and then operated on all at once. This may allow abstract operations over the input to naturally appear.
- The process of refactoring can be summed up in 3 steps. Read the code, gain insight about the code, push that insight into code structure to make that insight more obvious.
I really like the reliance on tests as a way to verify a refactor. Good tests should provide a tight feedback loop that ensure the refactor is improving the code instead of introducing bugs. Small commits that can be rebased allow for a constant clean state that can easily be rolled back to. It's also important to stay practical about refactoring. Refactoring could lead to abstraction into oblivion. Instead, just try to leave the code in a better state than you found it.