Chapter
6
Agile Coding
Any fool can make things bigger, more complex, and more violent. It takes a touch of genius—and a lot of courage—to move in the opposite direction.
When you start on a new project from scratch, the code is easy to understand and work with. As you progress with your development, however, you may find the project slowly turns into a monster, eventually taking more developers and an inordinate amount of effort to keep it going.
What turns a project that started out so well into a project that becomes hard to handle? As you worked on the tasks, you probably were tempted to take some shortcuts to save time. Often, however, a shortcut helps you only postpone a problem instead of solving it (as we saw in Quick Fixes Become Quicksand). It may come back to haunt you, and the rest of your team, as the schedule pressure mounts.
How can you keep the normal pressure in project development from creating stressful nightmares later? The easiest way is to keep your code well maintained. A small amount of effort each day while developing code can help you keep the code from rotting and keep the application from becoming hard to understand and maintain.
The practices in this chapter will help you develop code that’s easier to understand, extend, and maintain for the duration of the project and beyond. These practices will give you a sanity check to prevent your code from turning into a monster.
To begin, it’s better to be clear than clever as you Program Intently and Expressively, starting here. Comments can be helpful or a dangerous distraction; you should always Communicate in Code (that’s here). Nothing in engineering comes for free; you have to decide what’s more important and what the consequences of each decision are. You’ll need to Actively Evaluate Trade-Offs (it’s here) to make the best decisions.
Just as the project develops in increments, you will want to Code in Increments as well. See how, starting here. When writing code, it can be very hard to Keep It Simple—in fact, it’s harder to write simple code than to write nasty, overly complicated code. But it’s worth the effort, as we’ll see here.
Good object-oriented design principles suggest you should Write Cohesive Code, which we’ll talk about here. An excellent way to keep your code untangled and clean is to observe the Tell, Don’t Ask principle, described here. Finally, you can keep your code flexible in an uncertain future by designing the system such that you can Substitute by Contract, which we’ll look at here.