April 7, 2009
SPA2009 Session Practical - Scalable.NET Design Reviews Using Automated Code AnalysisIf you can't make it to Software Practice Advancement 2009 this afternoon (or of you did make it and you want a reminder), here's a Flash movie of the practical elements of the session created in advance using the indispensible Camtasia Studio.
The thrust of my argument - because my arguments tend to thrust, dontcha know - is that code/design inspections are a form of testing, and when we do testing manually it's very labour intensive and doesn't scale cost effectively. For the exact same reasons that we automate functional tests, we should aim to automate our design/code quality tests as much as possible so that we can spot problems early and deal with them cost-effectively.
One thing we'll probably discuss is how we tackle design/code quality in an Agile, Scrum-like process. Well, if we're doing TDD, then I would suggest beng test-driven about it might work best. Along with your user stories, you could write "quality stories", like "As a design authority, I require that methods are kept short so that they're easier to test and easier to understand" and then developers could stick that in the backlog and champion it's inclusion in iteration planning*. When someone picks up that quality story, they could go to the design authority and agree acceptance tests - and this is where our automated analysis comes in. We could use a tool like NDepend to detect long methods, and if they fall outside of an agreed tolerance we could raise the alarm almost as soon as a method grows too big. Maybe it makes the buid fail. Maybe we have to refactor it there and then to get the build green again. Well, a man can dream, can't he?!
The examples use NDepend, but the principles can be applied using a whole bunch of tools that focus on a whole bunch of different aspects of design quality.
* And yes, I know giving the customer the choice will almost certainly mean that no quality stories ever get scheduled. In which case a portion of the budget should be controlled by the developers (e.g., 20%) so they can make sure at least some of it gets done.
Posted 10 years, 2 months ago on April 7, 2009