DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. How to Add Static Analysis to Your Development Process

How to Add Static Analysis to Your Development Process

Erik Dietrich addresses the rising importance of introducing static analysis to your development lifecycle.

Erik Dietrich user avatar by
Erik Dietrich
CORE ·
Apr. 13, 16 · Opinion
Like (5)
Save
Tweet
Share
3.60K Views

Join the DZone community and get the full member experience.

Join For Free

As a consultant, one of the more universal things that I’ve observed over the years is managerial hand-waving.  This comes in a lot with the idea of agile processes, for instance.  A middle manager with development teams reporting into him decides that he wants to realize the 50% productivity gains he read about in someone Gartner article, and so commands his direct reports or consultant partners to sprinkle a little agile magic on his team.  It’s up to people in a lower paygrade to worry about the details.

To be fair, managers shouldn’t be worrying about the details of implementations, delegating to and trusting in their teams.  The hand-waving more happens in the assumption that things will be easy.  It’s probably most common with “let’s be agile,” but it also happens with other things.  Static analysis, for example.

If you’ve landed here, it may be that you follow the blog or it may be that you’ve googled something like “how to get started with static analysis.”  Either way, you’re in luck, at least as long as you want to hear about how to work static analysis into your project.  I’m going to talk today about practical advice for adding this valuable tool to your tool chest.  So, if you’ve been meaning to do this for a while, or if some hand-waving manager staged a drive-by, saying, “we should static some analysis in teh codez,” this should help you get started.

What is Static Analysis (Briefly)?

You can read up in great detail if you want, but I’ll summarize by saying that static analysis is analysis performed on a codebase without actually executing the resultant compiled or interpreted code.  Most commonly, this involves some kind of application (e.g. NDepend) that takes your source code files as input and produces interesting output by running various analyses on the code in question.

Let’s take a dead simple example.  Maybe I write a static analysis tool that simply looks through your code for the literal string “while(true)” and, if it finds it, dumps, “ruh-roh” to the console.  I’m probably not going to have investors banging down my door, but I have, technically, written a static analysis utility.

How This Fits

Let’s assume that you’ve gotten your hands on something a little more useful than my example.  What does this mean for development teams?  You have something that can analyze your code and give you feedback on it, but what can you do with it, exactly?
To an extent, that’s going to depend on what information, exactly, the tool doles out.  For simplicity’s sake, since this is an introductory explanation, let’s consider two very basic types of information often yielded by analysis tools.

  • A warning that a given piece of code may be buggy.
  • A warning that a given piece of code may be difficult to maintain.

Let’s again consider the mechanics.  Some static analysis tool takes your codebase as input, does its thing, and spits out a couple of lists.  One list points to a bunch of lines or methods in your codebase and says, “this one might be harboring a bug” and the other list points to a bunch of lines or methods and says “these are going to be hard for you to maintain.”

The Most Basic Approach

With this tool sitting on your development machine alongside your source code, the simplest thing you could do would be to execute it and take in the information it offers.  And that’s an excellent place to start.  The journey of 1,000 miles begins with a single step and all that.

Run it, see what it says, and then start some conversations.  Talk to others on your team about the tool and its output.  It will likely spark some interesting conversations ranging from, “yeah, that DoAllTheThings() method is terrible, but I guess I didn’t realize how terrible” to “I don’t agree with that at all!”  It tends to run the gamut.

But, you know what?  Whatever people say, it gets them talking, debating, and, most importantly, reasoning about the code.  It gets the team used to the idea that there’s more to code than simply “works or doesn’t.”  Code can be risky, and some code costs more than other code to own.

So start with the conversations, and let those around you get used to the water temperature.

Incorporate Static Analysis Into Code Review

Now that you’ve been having some spontaneous discussions about the code and people are acclimated to the tool, there’s a logical next step.  Introduce it into your code review process.  (Also, if you’re not doing code reviews, start doing code reviews.)

This will generally be preceded by some agreement upon which outputs of the analysis tool to abide by and heed, and there may be some tuning that needs to happen.  But the general idea is to add more rigor to the reasoning about code that happens.  It also has nice side effects, in the case of our two types of information.  It makes code review about catching potential defects, and it makes code review about keeping problematic code in the team’s consciousness as needing to be addressed.

Integrate Static Analysis Into The Build

Once people are comfortable with the analysis tool and used to incorporating it into reviews, the next logical step is build integration.  This is where you integrate the analysis tool into your team’s build — the build automation that happens anytime someone delivers code to source control.  (Also, if you don’t have CI and build automation, start having CI and build automation).

You’ve been using the tool as an aid to perform code reviews, but now it’s time to automate and remove the human element, at least from the parts that can be automated.  So if “that method might be buggy” always triggers a rework following code review, stop worrying about it at code review time.  Instead, just make the build fail if that particular warning occurs.  Implementing this strategy, you can save code review time for less cut and dry, more discussion-oriented activities.

Your Mileage May Vary

What I’ve outlined here is an incredibly simple overview of how you might work static analysis into your team’s approach.  It is intended to make the concept a little more concrete if you’re wondering about how to implement it.  But I cannot possibly account for every nuance and unique situation.

Still, this should arm you with enough to get started.  And, hopefully, this will allow you to deliver in response to even the vaguest of hand-waving on the matter.

agile Continuous Integration/Deployment

Published at DZone with permission of , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Three SQL Keywords in QuestDB for Finding Missing Data
  • Data Mesh vs. Data Fabric: A Tale of Two New Data Paradigms
  • GPT-3 Playground: The AI That Can Write for You
  • Problems of Cloud Cost Management: A Socio-Technical Analysis

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: