Divide et impera

Following this ancient rule (and Uncle Bob's suggestions) we recently separated our new development effort into four subproject, each of which focuses on a particular aspect of the whole project. The separation is also based on the techniques for splitting the different domain aspects explained in DDD.

Everything has been integrated in Hudson, with the Cobertura, Open Tasks and Violations (with PMD) plugins.

We still have to reintroduce JDepend, but we'll do it in a short while.

Hudson and Cobertura

I've finally managed to setup a Continuous Integration (CI) server (you waterfall people can find a wonderful explanation on CI here). My choice fell on Hudson, a simple but effective server wich can be expanded with a bunch of plugins, which you can also write by yourself. But, being programmers lazy guys, and not wanting to be an exception, I scanned the published plugin list and picked the Cobertura Plugin. After some head-banging on the wall (yes, programmers never read the instructions) I tweaked the right files and had all the system running and configured for a pilot project: now the system periodically updates the local repository, builds the project, injects the Cobertura code ("instruments the classes bytecode" would probably be a better description), runs all the tests and displays the report on test results and code coverage. And if someone has broken the build it sends her a warning mail. Thanks again to Fabrizio for the inspiration.

The next plugin I'm going to try is the Google Calendar Plugin (my most informed friends know why).

Legacy software and code coverage

According to Michael Feathers, software is considered legacy if it does not have automated tests supporting it. And, not surprisingly, there are (too) many legacy applications out there. And that raises a couple of questions: how do you change legacy code? yes, but how do you change it without feeling the urge to update your cv? Mr Feathers gives a lot of hints on changing code and dependencies-breaking techniques, presenting you with different problems and possible (and tested, of cours) approaches.
At the moment I am working on an "inherited" old (and, yes, legacy of course) application for which I'll have to check several chapters of Feather's book: I can't get this class into a test harness, I can't run this method in a test harness, dependencies on libraries are killing me, my application is all API calls, my project is not object oriented how do I make safe changes, this class is too big and I don't want it to get any bigger, I'm changin the same code all over the place, I need to change a monster method and I can't write tests for it, how do I know that I'm not breaking anything, and so on and so forth.
So... where to start from? The answer is quite simple: I have to write tests. OK, that was easy. Which tests should I write first? short question, long answer. Long story short: check the book for that. But how do I know what's covered and what's not? Thanks to Fabrizio I've discovered Cobertura, a test coverage tool which instruments the bytecode of your classes and produces reports about, well you guessed, test coverage; you can see a sample report here. Fabrizio shows how to integrate Cobertura in NetBeans, which happens to be my favorite IDE. I did it and... well... I have quite a lot of work ahead, but at least I have a new tool.