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!