How strongly do I recommend Refactoring?
7 / 10
Review of Refactoring
I recommend Refactoring particularly for mid-level developers with a few years experience. With a few years experience you can identify dirty code but haven’t developed the skills to iteratively transform your dirty code into clean code. That’s where Refactoring comes in.
Refactoring provides two things:
- A catalog of tactics we can apply to dirty code to improve shape and structure
- A philosophy around iterative improvements to code rooted in small changes, automated testing, and fast feedback loops
Top Ideas in This Book
- The rhythm of refactoring is quick and iterative: test, small change, repeat
- Code decays at a non-linear rate and refactoring helps preserve the shape of code to prevent rapid decay
- To teach and learn refactorings, we need to name them
- Code needs to work correctly before you refactor
- Each refactoring strategy is a skill we can acquire, demonstrate, and evaluate our performance with
- Most refactorings are small and daily, so be wary of developers asking for large chunks of time for refactoring
The rhythm of refactoring is quick and iterative: test, small change, repeat
Refactoring thrives on fast and tight feedback loops. Run a test, see it pass, refactor, rerun the test, over and over.
As the developer refactoring code, you always want to demonstrate functional stability as evidenced through tests.
To achieve fast feedback loops and functional stability, we benefit from fast automated testing. So as a technical leader, your job is to ensure the infrastructure around your developers is fast enough and reliable enough to facilitate the good behavior of automated testing and refactoring.
Code decays at a non-linear rate and refactoring helps preserve the shape of code to prevent rapid decay
Code follows a “broken windows” model, where decay happens in bursts through inattention. As a developer your job is eternal vigilance over the quality of code.
To teach and learn refactorings, we need to name them
Knowing the names of refactoring strategies helps us discuss them in a group context, bringing both clarity and conciseness to our communications.
Code needs to work correctly before you refactor
If your code isn’t working yet, you’re probably not ready to refactor. You want to operate from points of functional stability to prevent regressions.
Where developers get into trouble is trying to add new functionality or fix bugs while also refactoring. You probably need to learn this lesson the hard way though, where you’ve fixed something while refactoring, only to discover that nobody understands your pull request and you’ve actually created regressions.
Each refactoring strategy is a skill we can acquire, demonstrate, and evaluate our performance with
Our growth benefits from understanding the difference between knowledge and skill. Knowing how to do something is not terribly valuable. Demonstrating skill mastery is highly valuable.
Refactorings have tangible deliverables, which means developers can demonstrate our skills with specific refactoring and managers can assess our performance in those skill areas.
Most refactorings are small and daily, so be wary of developers asking for large chunks of time for refactoring
A lot of mid-level developers make the mistake of requesting big chunks of time for refactoring. That’s a sign they understand the code is dirty but they don’t really understand how to reshape it.
Refactoring is a daily workflow activity involving small changes. When a developer asks you for a big chunk of refactoring time, work directly with them to start implementing small refactoring changes from this book so they begin to see refactoring through a more iterative lens.
