(New page: == 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 b...)
|Line 24:||Line 24:|
By [[Niclas Nilsson]]
This work is licensed under a
This work is licensed under a
Revision as of 01:31, 10 July 2008
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 write trendsetting 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, may it be 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 ten, hundred, or maybe thousand 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 would be retrofitted into another part of the system? Transaction handling, logging, authentication or auditing, maybe? 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 seems to often go together? In each place they operate on different objects, but in the end it means the same thing?
All that are 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 or any other thing, but the repetition won't go away unless someone does something about it. That someone is you.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Software Architect Should Know home page