Improving Your Craft with Static Analysis
These days, I make part of my living doing what’s called “software craftsmanship coaching.” Loosely described, this means that I spend time with teams, helping them develop and sustain ways to write cleaner code. It involves introduction to things like the SOLID Principles, design patterns, DRY code, pair programming, and, of course, automated testing and test driven development (TDD). I’ve spent a lot of time contemplating these subjects and their economic value to organizations, even up to the point of creating a course for Pluralsight.com about this very thing. And through this contemplation, I’ve come to realize that TDD is an extraordinarily nuanced practice, both in terms of advantages offered and challenges presented.
This post is not about TDD, so what I’d like to do is zoom in on one particular benefit offered by the practice. It’s a benefit that tends to be overlooked beside the regression suite that it generates and the loosely coupled design that it encourages. But one of the important things that TDD does is to provide a very tight, automated feedback loop. Consider what generally happens if you’re working on a web application and you want to evaluate the effects of your most recent changes to the code base. You build the code and then run it, and running it is generally accomplished by deploying it to some local version of a web server and then starting the web server. Once the web server and your web application are running, you then engage the GUI and navigate to wherever it is that will trigger your code to be run. Only at this point do you get feedback about what you’ve done. TDD short-circuits this process by requiring only build and execution of a test suite.
Of course, TDD isn’t the only way to create a tight feedback loop, but it is a well recognized one. And it’s also one that tends to spoil you. After becoming used to TDD, it’s hard to go back to waiting for long cycle times between writing code and seeing the results. In fact, it tends to go the other way and you find yourself chasing other means of obtaining fast, automated feedback. It was this exact dynamic that got me hooked on the idea of static code analysis. If I could get quick feedback from unit tests about whether my code worked, why couldn’t I get feedback about whether it was well written?
This was a post I originally wrote for Infragistics. Please click here to read the rest, and thanks for reading!
Probably the only thing I’d add is a list of said tools. Most of us that have been in the biz long enough could rattle off some names, but exposing new folks (or purchasing managers) to those tools could be useful. I’m not sure what relationship you have with Infragistics, so that may play into things.
Infragistics didn’t weigh in on this, per se, but the post being intended for their blog is why I didn’t mention other vendors specifically. I get the sense that it would probably have been okay with them as long as the vendors I mentioned weren’t competitors, but I figured I’d avoid the situation.
Anyway, I love, love, love NDepend for static analysis. With the CQLinq, there’s just nothing out there like it, IMO.
Nice article @daedtech:disqus ! May I mention my list of static analysis tools here as well? Here’s the link: https://github.com/mre/awesome-static-analysis
There’s some nice gems in there which are missing in the Wikipedia list. Have fun.
That’s a great list! Probably the most comprehensive I’ve seen. One I’d suggest is that you check out NDepend for C#.
Oh thanks! Just added it and mentioned you in the commit message: https://github.com/mre/awesome-static-analysis/commit/96da81c1991b25f8a659144e5702878fcff7402e 🙂