2 Looking under the hood of refactoring

In the last chapter, we took a look at the different elements involved in refactoring. In this chapter, we dive into the technical details to form a solid foundation of what refactoring is and why it is important from a technical perspective.

2.1 Improving readability and maintainability

We start by reiterating the definition of refactoring that we use in this book: refactoring is making code better without changing what it does. Let’s break down the two main components of this definition: making code better and without changing what it does.

2.1.1 Making code better

We already saw that better code excels in readability and maintainability and why that matters. But we did not discuss what readability and maintainability are, or how refactoring affects them.

Readability

Readability is the code’s aptitude for communicating its intent. This means that if we assume the code works as intended, it is very easy to figure out what the code does. There are many ways to communicate intent in code: having and following conventions; writing comments; variable, method, class, and file naming; using whitespace; and so on.

2.1.2 Maintaining code . . . without changing what it does

2.2 Gaining speed, flexibility, and stability

2.2.1 Favoring composition over inheritance

2.2.2 Changing code by addition rather than modification

2.3 Refactoring and your daily work

2.3.1 Refactoring as a method for learning

2.4 Defining the “domain” in a software context

Summary