1 Introduction
It is well-known that high code quality leads to cheaper maintenance, fewer errors, and happier developers. The most common way to get high code quality is through refactoring. However, the way refactoring is usually taught — with code smells and unit testing — imposes an unnecessarily high barrier to entry. I believe that anyone can execute simple refactoring patterns safely, with a little practice.
Figure 1. 1. Skills, culture, or tools
In software development, we place problems somewhere on the diagram shown in figure 1.1, indicating a lack of sufficient skills, culture, tools, or a combination of those. Refactoring is a sophisticated endeavor and therefore lies right in the middle. It requires each component:
- Skills. We need the skills to know what code is bad and needs refactoring. Experienced programmers can determine this through their knowledge of code smells. But those are fluffy and not easy to learn; and to a junior developer, understanding code smells can look more like a sixth sense than a skill.
- Culture. We need a culture and workflow that encourage taking the time to perform refactoring. In many cases, this is implemented through the famous red-green-refactor loop used in test-driven development. However, test-driven development is a much more difficult craft, in my opinion. Red-green-refactor also does not easily give way to doing refactoring in a legacy codebase.