Adding Static Analysis to Your Team’s DNA
Editorial note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. While you’re there, download NDepend and play with adding it to your team’s build.
Stop me if this sounds familiar. (Well, not literally. I realize that asynchronous publication makes it hard for you to actually stop me as I type. Indulge me the figure of speech.) You work on a codebase for a long time, all the while having the foreboding sense of growing messiness. One day, perhaps when you have a bit of extra time, you download a static analyzer to tell you “how bad.”
Then you have an experience like a holiday-time binge eater getting on a scale on January 1st. As the tool crunches its results, you wince in anticipation. Next, you get the results, get depressed, and then get busy correcting them. Unlike shedding those holiday pounds, you can often fix the most egregious errors in your codebase in a matter of days. So you make those fixes, pat yourself on the back, and forget all about the static analyzer, perhaps letting your trial expire or leaving it to sit on the shelf.
If you’re wondering how I got in your head, consider that I see this pattern in client shops frequently. They regard static analysis as a one time cleanup effort, to be implemented as a small project every now and then. Then, they resolve to carry the learning forward to avoid making similar mistakes. But, in a vacuum, they rarely do.
A Better Course of Action: Incorporate the Tool
For the remainder of the post, I’ll refer to NDepend, both because of my familiarity with it and because it seems entirely appropriate for the NDepend blog. But the principles here could apply to many static analyzers or other types of tools.
Simply put, you should not forget the tool. On the contrary, you should expand your relationship with it. You should add it to your build and to your process as a developer.
This approach requires very little effort. At a bare minimum, you can modify your build to generate a report and run the tool prior to each commit. Doing this tightly integrates code quality and trends into your development process. They become constant fixtures, rather than periodic, one-off projects.
But that covers the “how” and not so much the “why.” Let’s address that in the remainder of the post. What benefits do you realize from using NDepend on a continuous basis?