Chapter 5. Refactoring

© Jennifer M. Kohnke

The only factor becoming scarce in a world of abundance is human attention.

Kevin Kelly, in Wired

This chapter is about human attention, about paying attention to what you are doing and making sure that you are doing your best. It is about the difference between getting something to work and getting something right. It is about the value we place in the structure of our code.

In Refactoring, his classic book, Martin Fowler defines refactoring as "the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure."^[1] But why would we want to improve the structure of working code? What about "If it's not broken, don't fix it!"?

^[1] [Fowler99], p. xvi

Every software module has three functions. First is the function it performs while executing. This function is the reason for the module's existence. The second function of a module is to afford change. Almost all modules will change in the course of their lives, and it is the responsibility of the developers to make sure that such changes are as simple as possible to make. A module that is difficult to change is broken and needs fixing, even though it works. The third function of a module is to communicate to its readers. Developers who are not familiar with the module should be able to read and understand it without undue mental gymnastics. A module that does not communicate is broken and needs to be fixed.

What does it take to make a module easy to read and easy to change? Much of this book is dedicated to principles and patterns whose primary goal is to help you create modules that are flexible and adaptable. But it takes something more than just principles and patterns to make a module that is easy to read and change. It takes attention. It takes discipline. It takes a passion for creating beauty.