Chapter 3. Preparing to refactor

 

This chapter covers

  • Getting everybody on board with your plan for refactoring
  • Deciding whether to refactor or to rewrite from scratch
  • Deciding what is and isn’t worth refactoring

In this chapter we’ll tackle some of the nontechnical issues that you’ll often face when carrying out a major refactoring on a real-world codebase. In an ideal world, you’d have complete freedom and unlimited amounts of time to craft beautiful code, but the reality of software development often demands compromise. When you’re working as a member of a team, which in turn is part of a larger organization with plans and goals, budgets and deadlines, you’ll need to hone your negotiating skills in order to achieve consensus from both your fellow engineers and nontechnical stakeholders on the best way to proceed.

After that I’ll give you a friendly reminder that refactoring should always be done with the goals of the organization in mind. In other words, don’t forget who pays your salary! Refactoring should be done only if you can prove that it provides long-term value to the business.

3.1. Forming a team consensus

3.2. Gaining approval from the organization

3.3. Pick your fights

3.4. Decision time: refactor or rewrite?

3.5. Summary