Contribution 63

From WikiContent

Revision as of 05:00, 10 July 2008 by Rmonson (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Fight repetition

Are your developers performing some recurring tasks that needs little thinking? Can you find recurring patterns in the code? Can you spot code that's been written by copy-paste-modify? In that case, your team is moving slower than they should. And that may be your fault.

Before explaining why, let's refresh a few common truths about software development: Duplication is evil. Repetitive work slows down development. Flow is an important part of software development. Old truths, but important ones.

As an architect, you're the one with the best overall grasp of the system and the code base. It's you who promote how things are done, and it's you who will write trend-setting parts of the system. You set the tone.

You've likely written an end-to-end, vertical slice of the system that serves as an example for the team. That example slice will be copied, over and over again.

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 simpler or even completely abstracted away. Most often, it's not domain logic that is copied; it's infrastructure code that just has to be there to make it work.

Because of that, it's crucial that you can envision the effects of your examples. Code and configuration in there will be the base for tens, hundreds, or maybe thousands other slices of the system. You have to make sure that your code is clean, intention revealing, and contains 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 do will (ironically) be repeated.

Take that configuration file. What needs to be different for another slice of the system? How much does not need to be changed?

Look at a typical method. Is there a pattern that will be repeated if that method is retrofitted into another part of the system? Transaction handling, logging, authentication or auditing? How about the data access layer? Any data access code that will similar except for names of entities and fields?

Look around the code base a bit broader. Can you find two, three lines of code that frequently seems to go together? In each place they operate on different objects, but in the end it means the same thing?

They are all redundancies. It's a pattern that the developers eventually will learn to filter out and simply ignore when reading the code, once they figured out where the interesting variabilities are. That code is clearly written for the computers execute, not for developers to read. In the end, it's just noise. And it's your responsibility to remove it.

You may need to harvest frameworks, create better abstractions, ask the toolsmith to setup an aspect framework, write a few small code generators, but the repetition won't go away unless someone does something about it. That someone is you.

(RMH Edited 7/9/2008)

By Niclas Nilsson

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Software Architect Should Know home page

Personal tools