delphiXtreme

Take the following test:

1. Take a class, any class and instantiate it in a test harness.
2. Find a coworker, let them read your code and tell you what it does.
3. Count the instances of duplication in your code.

Why take this test?

Number 1.
The ability to instantiate any class in a test harness demonstrates the level of decoupling and cohesion of your code. Why is that good? Highly decoupled cohesive code promotes: seperation of concerns, low duplication and extensiblity. You end up with only as much code as you need. You also get the power to duplicate and isolate customer found defects before fixing them, giving you a collection of tests you can rely on to prove the integrity of your code and design.

Number 2.
To often we write code that is write-once/read-never. Your code should be expressive of it’s intent and easy to read. It should do what it says and say what it does. Code spends more time being read and maintained than being originated. Additionally, when you’re writing highly decoupled code the more readable your code the more likely someone can come behind you and maintain/extend your work.

Number 3.
Duplication is the bane of maintainability. You (and I) have copy-and-pasted code from one unit to another to tweak it for some slightly different functionality. Stop it. Refactor that code into a superclass or into seperate object and use a subclass for specific functionality (see the Strategy Pattern). Duplication has more than one face: copy-and-paste (as I just talked about), and reinventing the wheel. On a larger team it easy to reinvent functionality that another team member wrote prior to you. Don’t be afraid to query your peers when you get that “someone must have done this before” feeling. You’ll reduce the complexity and size of your project by eliminating functional duplication.

How do you get there?

Check out:

• Eric Evans’s Domain Driven Design (don’t be put off by this rather large volume, it’s worth the read).
• Dan North’s thoughts on Behavior Driven Development - especially the precept of working from the outside in (which lines up with the “eat your own dog food” principle).
• Martin Fowler’s Refactoring (great book)
• Design Patterns - I really liked Head First Design Patterns by Eric Freeman, et al.
• Refactoring to Patterns by Joshua Kerievsky

So how did it go? Post your test experience in the comments.

Full Disclosure
I stood on the shoulders of the following giants to write this post:
Dave Astels
Michael Feathers

XP design, engineering, testing