Recently one of my friends from work asked me to help him improve the process around code quality and developer productivity. So I compiled my thoughts and e-mailed to him, but then I realized that it may be very helpful for others who are involved in software industry. Are you? Then keep reading.. :)
Although tools and frameworks listed here are JVM-based language focused, the approach can be definitely reused with any other environment / language / technology. So without further ado, here it goes:
The center of the code quality monitoring can be either Continuous Integration ( e.g. Cruise Control: http://cruisecontrol.sourceforge.net/ ) or Sonar ( http://sonar.codehaus.org/ ). Sometimes both.
Continuous Integration should be setup to “Intergarte Continuously” :) which means every time something is checked in, force a build. That is the whole purpose of “Continuous Integration”, and that is why I am really against the way Cruise Control is used on some client sites [builds on demand by pressing a build button.. grrr, back to 1990-ties].
So given that “Continuous Integration” is not misused, it will be plugged in with PMD ( http://pmd.sourceforge.net/ ) / Findbugs ( http://findbugs.sourceforge.net/ ), Checkstyle ( http://checkstyle.sourceforge.net/ ) and Test Coverage ( e.g. Cobertura: http://cobertura.sourceforge.net/ ) tools that will generate reports, and reflect the only true state of the code that is checked into the repository.
Now, as to a developer corner..
RAD is nothing more than just an Eclipse with lots of bloated (mostly unused IBM plugins). But being Eclipse it is very pluginable by nature. This means that PMD / Checkstyle / Cobertura reports can be available to developers prior checking in the code. PMD / Checkstyle at compile time, Cobertura at (test) run time. If possible, try to use something like Spring Tool Suite: http://www.springsource.com/products/sts, which is also an Eclipse, but much lighter (compare to RAD), faster and smarter “pluged-in”.
As far as testing. JUnit (http://www.junit.org/) should be aimed to cover two different separate layers of testing: Component/Unit Testing and Integration Testing. Component tests should be aimed to test exclusively content of the component with all of its dependencies mocked out ( http://mockito.org/ ). Where as Integration tests should test how well components integrate together, with all the test data staged ( in case DB is used: http://www.dbunit.org/ )
As for the test coverage, 85% to 90% is a good goal to aim for. Do not sign off, until this level of coverage is reached no matter how close your dead lines are, since if you do, that will increase amount of defects ten fold, that is just a law :)
If developers work on code that is / can be deployed to an Application Server, such as Tomcat, JBoss, Geronimo ( if you’re unlucky, Websphere :) ), consider getting JRebel ( http://www.zeroturnaround.com/jrebel/ ), it’ll boost developers productivity by.. let’s just say “a lot” :)
This is how I see it, and this really works for me, and projects around me.