When I look at code, the first thing that pops into my head is “Is this readable?” Can I quickly glance at a class or a method and understand what it does? Is the interface clear, are side effects obvious, and are there consistent patterns that tell other developers how to use the software?
We value readability, both in our source code and in our tests. Cogent tests express the intent of the code, whereas verbose tests with a lot of set up muddle the intent. The beauty of TDD is that it enables you to write the code that you wish you had.
We pair program, which lets us propagate patterns throughout the code base. As we build a feature, we’ll often take on minor refactorings to make the code more consistent. The problem is that not all refactoring is “minor.” A convenient way to categorize refactorings is in units of time – is this a refactor that will take minutes, hours, days, or weeks? The ones that take minutes/hours are no-brainers and should be done; the ones that take days/weeks often involve discussion and need to be balanced with the priorities of the business.
When I say that we value readability, I’m not talking about code that is pretty for pretty’s sake. The goal is not to stare at our code and sigh “ooooh.” The goal is to have code that satisfies existing business needs and can be easily adapted for new features. Code that is simple and readable has a lower cost of change – there’s less cognitive overhead and less time spent untangling what something does. Our goal is to make the cost of change cheap so that we can quickly respond to business needs.