This is a guest posting by Jim Holmes
In an earlier article, we discussed five code metrics that can help you and your organization better test your software. This article focuses on static analysis tools themselves, and how to implement them in your environment. You’ll also see how such tools can help you begin to address larger technical debt and overall code health quality issues.
Static Analysis Overview
Static analysis (SA) tools examine the health of your codebase. They don’t analyze your system while it’s running–that’s the purview of dynamic analysis tools. Instead, SA tools work with the code files themselves, and also with compiled binaries, to examine various measurements of your software’s maintainability, complexity, and other metrics that are terrific indicators of potentially troublesome sections of code.
Static analysis tools offer a number of measurements about your codebase. In some cases, an overwhelming number! For those new to static analysis and code quality metrics, here are some quick go-to metrics when starting to examine a codebase’s health:
- Number of Comments in Code. Comments frequently become disconnected from the code they’re describing. This leads to confusion about which is supposed to be the “right” thing: the comment or the code.
- Overly Long Classes and Methods. Long classes and methods generally indicate too much is going on–a violation of the Single Responsibility Principle.
- High Coupling. Lots of dependencies in or out of a class or module make it hard to change the system,
- Cyclomatic Complexity. My number one super villain of code health. Overly complex blocks of code are hard to test and statistically proven to contain more bugs.
Using Static Analysis Tools Locally
Many static analysis tools can run locally on a developer’s or tester’s system. Some tools, like NDepend, can be run as a standalone tool. Others, like Iris or CodeRush, are plugins for larger Integrated Development Environments (IDEs) such as IntelliJ for Java or Visual Studio for .NET respectively. Being able to run SA metrics locally is a tremendous benefit for a number of reasons.
First, good SA tools allow a user to focus on one particular metric or one specific area of the codebase. This can be a great help when working an exploratory testing session on a functional slice, user story, or aspect of the system. The tester or developer can use something like the CodeRush plugin for Visual Studio to see metrics right in the editor window.
CodeRush plugin showing maintainability metric.
Secondly, tools like NDepend give the user a great high-level visualization of selected metrics, showing off hotspots or problematic sections from the top down. Again, this is extremely helpful when planning out spelunking or exploratory testing–it’s easy to see which sections of the codebase are problematic.
Static Analysis Tools in Your Continuous Integration / Continuous Delivery Pipeline
Running static analysis tools in your continuous integration or continuous delivery pipeline is an extraordinary step to growing a mature, well-running team. Tools such as NDepend, SonarQube, and others can run right in your build toolchain, either as plugins to servers like Jenkins or as external processes. This means you can tie static code analysis right into your overall delivery pipeline.
All respectable, mature static analysis tools allow you to configure thresholds for each metric they measure. This means you can create pass/fail criteria for your most critical quality concerns. For example, you can configure the tool to fail the build if cyclomatic complexity is over a certain value, or if a specific module/component has too high a coupling metric.
With this capability, you can cause the entire build process to halt if any measurement breaks the threshold. This creates an automated rule-based policy for ensuring code quality remains at agreed-upon, publicized measurements.
Finally, good static analysis tools provide solid reporting features, enabling your team and organization to visually track metrics on quality dashboards. Trend tracking is an integral feature of these tools’ reporting, so you can measure and visualize your progress over time.
Static Analysis Tools Help to Address Technical Debt
Teams often have trouble narrowing down technical debt to specific, actionable items. Static analysis tools can be a great help in building up a technical debt paydown plan. This data is a tremendous help when creating go-forward plans with the business stakeholders. The stakeholders can offer up their main concerns, and the team can overlay those issues with data about codebase health. This will help to focus in on areas that may be quick wins and highlight sections that will take a longer, more disciplined approach.
Moreover, a team working to improve their overall code quality can configure the build process gates with high tolerances at first, then gradually dial them down as the team and codebase improve.
Conclusion
Static Analysis tools are a critical part of any team’s overall efforts to build and maintain great software. Learning how to use them in your environment is fairly simple, and can be a great asset to your organization.
Jim is an Executive Consultant at Pillar Technology where he works with organizations trying to improve their software delivery process. He’s also the owner/principal of Guidepost Systems which lets him engage directly with struggling organizations. He has been in various corners of the IT world since joining the US Air Force in 1982. He’s spent time in LAN/WAN and server management roles in addition to many years helping teams and customers deliver great systems. Jim has worked with organizations ranging from start-ups to Fortune 10 companies to improve their delivery processes and ship better value to their customers. When not at work you might find Jim in the kitchen with a glass of wine, playing Xbox, hiking with his family, or banished to the garage while trying to practice his guitar.
