- Taking Responsibility
- Applying Feedback
- Pragmatic Environment
- Coding Techniques
- Sign Your Work
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Coding Techniques
Before code can be agile, it must be robust. Before you can code for reuse, you must code for use. We could continue to fill the rest of this article with pithy aphorisms about the qualities that good code must possess, but it's probably easier just to show the basic principles that good code follows. If you follow these principles consistently, everything else good falls into place, and we can achieve our agile goal of writing code that bends, but doesn't break. Two of the most important of these principles of coding are called DRY and orthogonality.
DRY stands for "Don't Repeat Yourself"; it's a fundamental pragmatic principle that states: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." This is similar in spirit to extreme programming's "once and only once" rule, but is more far-reaching, as it goes beyond code to impact every aspect of the system, including documentation, build and environmental parameters, and so on.
For example, you may be writing code to create a flat file in a particular format. That format may be expressed in a table with column names, field types and lengths, and other processing notes. In a typical project, this table will appear in many forms: in a Microsoft Word requirements document, in a code comment block, in the code itself, and in the end-user HTML documentation. What a maintenance nightmare: Four things to change (in four different mediums) every time there's a change!
DRY says that there should be just a single representation of this information, and that you should use simple scripts to convert from this representation to the various other forms. One script might convert it to HTML for inclusion on the web site and in the requirements documentation (with different levels of detail), and another script may generate the Java methods or classes that perform the actual writing of the file. If the file format changes, changing just one representation and regenerating the rest means that maintenance becomes simple. And of course, as we suggested previously, you'll have automated this generation as part of your build system, so the change becomes even less painful.
Many people misunderstand this principle at first reading. They view it as a mechanical thing—a rule that you can't have the same sequence of characters at two places in the code. That's not the philosophy behind DRY. It does mean that only one of the locations of the text is authoritative. The benefits are obvious: When a change needs to be made, you only need to make the change in one place, and it will automatically propagate as necessary. Simple techniques like this are crucial to maintaining agile code.
The other major technique goes by the code name orthogonality. We use this mathematical term to describe a simple principle: Unrelated things must remain unrelated. One of the biggest contributors to accidental complexity in a system is unintentional coupling—two pieces of code that shouldn't be related become locked in a death grip. This can become a viral problem, spreading through the system rapidly until every class depends on every other class.
Suddenly you notice that your spaghetti has grown to the point where you require the entire system just to run one simple unit test. As with other broken windows, the solution is to remain ever vigilant, and to decouple unrelated things—break the dependency—as soon as you realize the need.