Part 2. Refactoring to improve the codebase

We set up the inspection infrastructure in chapter 2, and we’re now ready to start work on re-engineering our legacy software.

Chapter 3 will focus on a very important decision, namely whether to refactor a codebase or to throw it away and rewrite from scratch. This decision is often risky, because it’s made at the start of the project when you don’t yet have much information to guide you, so we’ll also look at how to reduce that risk by taking a more incremental approach.

Chapters 4, 5, and 6 look in detail at three options for re-engineering software: refactoring, re-architecting, and the Big Rewrite. In a sense, they’re all variants of each other, just working at different scales. Refactoring is restructuring of code at the level of methods and classes, re-architecting is refactoring at the level of modules and components, and the Big Rewrite is re-architecting at the highest possible level.

In chapter 4, I’ll introduce a number of refactoring patterns that I’ve often used or seen used successfully. In chapter 5, I’ll provide a case study of splitting a monolithic Java application into a number of interdependent modules, and I’ll also touch on the comparative merits of monoliths and microservices. Finally, in chapter 6 I’ll provide tips for achieving a successful rewrite of a large piece of software.