Refactor Every Time You Touch Code or Tests

I said earlier in this chapter that we want to keep the code and tests clean. You may have worked on a large product that had some automated tests. And eventually those tests didn’t work anymore. No one refactored those tests as the code changed.

Even worse, you may have seen projects where “all of a sudden” the build didn’t work. Often, the suddenness arises from lack of integration. But part of the problem is also that no one updated and simplified the code or the build scripts.

I’ve seen code bases where the code had several ways to get data and several ways to output data. They didn’t all work the same way. By the time a new team worked that code base, it needed to redesign the code, not refactor. I’m not suggesting that you never have to redesign, but refactoring simplifies and makes everything clear as you proceed. You are less likely to need to redesign.

Refactoring is simplification. It’s not redesign. It’s not rearchitecture. Refactoring—by itself—does not add features to a product. It’s entirely possible that when you add a feature you first add functionality. Then, you refactor to simplify.

Refactoring works for both code and tests.