How strongly do I recommend Refactoring?
7 / 10
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:
Top Ideas in This Book
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 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.
Knowing the names of refactoring strategies helps us discuss them in a group context, bringing both clarity and conciseness to our communications.
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.
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.
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.