I remember my earliest experiences with static analysis. Probably a decade ago, I started to read about it during grad school and poke around with it at work. Immediately, I knew I had discovered a powerful advantage for programmers. These tools automated knowledge.
While I felt happy to share the knowledge with coworkers, their lack of interest didn’t disappoint me. After all, it felt as though I had some sort of trade secret. If those around me chose not to take advantage, I would shine by comparison. (I have since, I’d like to think, matured a bit.) Static analysis became my private competitive advantage — Sabermetrics for programmers.
So as you can imagine, running it on the build machine would not have occurred to me. And that assumes a sophisticated enough setup that doing so made sense (not really the case back then). Static analysis was my ace in the hole for writing good code — a personal choice and technique.
Fast forward a decade. I have now grown up, worked with many more teams, and played many more roles. And, of course, the technological landscape has changed. All of that combined to cause a complete reversal of my opinion. Static analysis and its advantages matter far too much not to use it on the build machine. Today, I’d like to expand on that a bit.
Continue reading Static Analysis for the Build Machine?
I’ve made no secret that I spend a lot of time these days analyzing code bases as a consultant, and I’ve also made no secret that I use NDepend (and its Java counterpart, JArchitect) to do this analysis. As a result, I get a lot of questions about analyzing code bases and about the tooling. Today, I’ll address a question I’ve heard.
Can NDepend analyze a complex solution (i.e. more than 100 projects)? If so, how do you do this, and how does it work?
Can NDepend Handle It?
For the first question — in a word, yes. You certainly can do this with NDepend. As a matter of fact, NDepend will handle the crippling overhead of this many projects better than just about any tool out there. It will be, so to speak, the least of your problems.
How should you use it in this situation? You should use it to help yourself get out of the situation. You should use it as an aid to consolidating and partitioning into different solutions.
The Trouble with Scale
If you download a trial of NDepend and use it on your complex solution, you’ll be treated to an impressive number of project rules out of the box. One of those rules that you might not notice at first is “avoid partitioning the code base through many small library assemblies.” You can see the rule and explanation here.
We advise having less, and bigger, .NET assemblies and using the concept of namespaces to define logical components.
You can probably now understand why I gave the flippant-seeming answer above. In a sense, it’d be like asking, “how do I use NDepend on an assembly where I constantly swallow exceptions with empty catch blocks.” The answer would be, “you can use it to help you stop doing that.”
Continue reading How to Analyze a Complex Solution