Fight Repetition



Fight Repetition

Niclas Nilsson

ARE youR dEvElopERS performing recurring tasks that need little think- ing? Can you find recurring patterns in the code? Can you spot code that’s been written copy-paste-modify style? If that’s the case, your team is moving slower than it should and, oddly enough, you may be the cause.
Before explaining why, let’s agree on a couple of truths about software development:
• Duplication is evil.
• Repetitive work slows down development.
As an architect, you set the tone. You’ve got the best overall grasp of the system and you probably wrote a trend-setting, end-to-end, vertical slice of the sys- tem that serves as an example for the team—an example that has been copied many times by now. Whenever a developer copies anything—be it a few lines of code, an XML file, or a class—that’s a clear indication that something could be made simpler or even completely abstracted away. Most often, it’s not the domain logic that is copied; it’s the infrastructure code that just has to be there to make it work. For that reason, it’s crucial that you can envision the effects your examples have. Any code and configuration in your examples will be the base for tens, hundreds, or maybe thousands of other slices of the system, which means you have to make sure that your code is clean, intention reveal- ing, and containing nothing except what can’t be abstracted away: the domain problem itself. As an architect, you need to be highly sensitive to any kind of repetitive patterns, since anything you write will (ironically) be repeated.

But that doesn’t happen in your system, right? Take a look at that configura- tion file. What needs to be different if applied on another slice of the system, and what will stay the same? Look at a typical business layer method. Is there a pattern that shows up in other methods as well, containing things like transac- tion handling, logging, authentication, or auditing? How about the data access layer? Any code in there that will be the same except for names of entities and fields? Look broader. Can you find two or three lines of code that frequently seem to go together, and even though they operate on different objects, feel like the same thing? These are all examples of repetition. Repetition in code is something that developers eventually learn to filter out and ignore when read- ing the code, once they figure out where the interesting variabilities are found, but even if the developers get used to it, it slows them down. Code like that is clearly written for computers to execute, not for developers to read.
Your responsibility is to remove it. To do that, you may need to harvest frame- works, create better abstractions, perhaps ask the toolsmith to set up an aspect framework or write a few small code generators, but the repetition won’t go away unless someone does something about it.
That someone is you.