Taste-Driven Development

Having used Test-Driven Development for several years now, I am as convinced as I have ever been of its benefits in producing high quality maintainable code. One thing that bothers me, though, is that TDD itself provides no forces to ensure that the small pieces you build are assembled together into the higher-order structures you intended. For example, you can write a clean, concise fully tested set of classes such that your domain model is directly accessing your custom tags for your web app. Of course nobody interested enough in software to read this would ever do such a thing, but the point remains: with the promiscuous coupling encouraged by IDE's that will helpfully import any class from anywhere without requiring you to think whether this violates good taste in the form of layering, abstraction or anything else, we seem to be constantly having to fight against randomly coupled internal workings in good-sized systems.

So I find I'm constantly looking for ways to do what we do at the class level with TDD and do it at the package/component level; that is, allow the good taste desired in the design to be formally expressed and tested with every build. Developers who aren't up to speed yet on the complexities of the system they're working on would be protected from violating its conventions, and the emergent design can be allowed to flourish in a controlled way. On our current project we use a few things to help, such as simian, jdepend, ydoc, lots of checkstyle checks aimed at code quality and the usual test coverage stuff. But a few of us think that what the world really needs is yet another open source java development tool. Oh, no, you say, not another one. Yes, I'm afraid, it's another one. But this one is different - this one uses a business rule engine (drools) to allow you to declare in a text file your idea of good taste and enforce it for your code base. This one even has a user guide. No, seriously. So if design is your bag, have a look at joodi and let me know what you think. It only has a few rules in it at the moment, so it's not overly complicated.

Oh, by the way, if you think the java runtime itself would show good taste, check out what joodi has to say about rt.jar in the sample reports section of the user guide...you might be surprised!

Here's an example rule from the joodi rule file. This one expresses the simple good taste that cyclic package dependence is bad. It's kind of cryptic at first glance, but it basically says that if there exists a namespace (i.e. a java package) that depends on itself (dependence being part of the joodi fact model when your code is analysed), then create a notification including the cause of the problem so that the report provides full traceability for each notification produced. Using joodi is pretty much down to writing rules like this that express what good taste means to you and your project. Welcome to Taste-Driven Development!

<rule name="Cyclic Namespace Dependence Is Bad">
<parameter identifier="namespace">
<java:class>Namespace</java:class>
</parameter>
<java:condition>
namespace.dependsOnNamespace(namespace) != null
</java:condition>
<java:consequence>
drools.assertObject(new CyclicNamespaceUseNotification(namespace.dependsOnNamespace(namespace)));
</java:consequence>
</rule>