Are You Aggressively Trying to Automate Code Review?

Editorial note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, have a look at their automated analysis and documentation tooling.

Before I talk in detail about trying to automate code review, do a mental exercise.  Close your eyes and picture the epitome of a soul-crushing code review.

You probably sit in a stuffy conference room with several other people.  With your IDE open and laptop plugged into the projector via VGA cable, you begin.  Or, rather, they begin.  After all, your shop does code review more like thesis defense than collaboration.  So the other participants commence grilling you about your code as if it oozed your incompetence from every line.

This likely goes on for hours.  No nit remains unpicked, however trivial.  You’ve even taken to keeping a spreadsheet full of things to check ahead of code reviews so as not to make the same mistake twice.  That spreadsheet now has hundreds of lines.  And some of those lines directly contradict one another.

When the criticism-a-thon ends, you feel tired, depressed, and hungry.  But, looking on the bright side, you realize that this is the furthest you’ll ever be from the next code review.

It probably sounds like I speak from experience because I do.  I’ve seen this play out in software development shops and even written a blog post about it in the past.  But let’s look past the depressing human element of this and understand how it proves bad for business.

The Negative Value Proposition of Wasteful Code Review

When it comes to business, you cannot separate human outcomes from business outcomes.  I’ve seen organizations expend massive efforts to do so, but it simply doesn’t work.  So crushing the souls of the software development team also crushes the team’s productivity.

But even if you could wave a magic wand and make these reviews happy, collaborative exercises, you would still have waste.  That giant spreadsheet that I mentioned?  Doesn’t that seem like a yellow flag, if not a red one?  Software shops earn their living automating things.  Doesn’t a gigantic list of things to remember strike you as something ripe for automation?

As developers, we try to automate things almost unconsciously.  Tell me that you’ve never contemplated writing a script to help you rename 10 files instead of doing it by hand.  You know you’d spend way more time on the automation than you’d save in labor, but you still itch to do it.

But we fail to apply this thinking in contexts where, perhaps, the path to automation seems less obvious.  After all, how can you automate code review?  It’s an inherently collaborative, human-centric activity.  Right?

Well, parts of it qualify.  But others you can automate — and easily.  And failing to automate these parts results in developers sitting in a conference room bickering when they could be getting work done.  Let’s take a look at what review activities qualify for automation.

Would that Compile and Pass the Unit Tests?

First, let’s consider the most facepalm-inducing kind of activity for a discussion of how to automate code review.  I’m talking about the kind of review for which you already have automation tools at your disposal.

I have, in the past, witnessed people argue about what code would do at runtime.  But it gets worse.  I’ve heard arguments about whether or not at runtime the code would pass unit tests.  I’ve even heard arguments about whether or not it would compile.

Do you know what really helps when prognosticating about whether the code would compile?  The compiler!  The very same one that everyone on the team has constant access to.

Come to code review assuming that everyone compiles, runs the application, and runs the test suite.  Should that prove problematic, you have some training issues on your hands.  But even still, automate compiling and running regression tests as an upstream activity from code review so you don’t need to waste time debating how the test runner or compiler would treat a piece of code.

Don’t Bother with Cosmetic Concerns

I think that it would depress me to learn how many hours of my life involved listening to people point out cosmetic mistakes in code review.  Actually, our coding standard says that we Pascal case our class fields instead of camel casing them.  In response, the reviewee makes a note to fix it later or perhaps does it right in the moment.

This doesn’t quite rise to the level of debating whether or not code would compile.  But it does waste the entire team’s time.

First of all, you have productivity add-ins like Resharper that will modify code to conform to a standard automatically.  And secondly, on the build side, you can easily check for conformance to the team’s standard and kick back commits or fail the build.  It’s doubtless other automation opportunities exist as well.

The broader point remains.  You don’t need human intervention to figure this stuff out.  Machines and algorithms can easily do it for you.

Leverage Static Analysis/Automated Review Tooling

For the final automation category, I’ll get a bit more sophisticated.  Once you’ve made use of your compiler, test runner, and various linting/formatting tools, you can still go further.  You can shift the focus from eliminating drudgery in human code reviews to automating substance, in earnest.

For example, consider the idea of automated programming by contract.  Instead of having people look at a method without a defensive null check and speculating that null reference exceptions might arise, you can employ a tool.  Tools on software developers’ machines can help them reason about and guarantee method preconditions, post-conditions, and invariants.

Going beyond that, tools like CodeIt.Right exist.  Using these, you can leverage hundreds of automated checks for compliance with established industry practices and norms.  You can think of this as an extremely sophisticated extension of the compiler’s warning system; these give you heads up about a whole assortment of questionable coding practices.  And you can even tailor them to your team’s specific preferences, disabling any warnings you consider noise or don’t agree with.

When you improve your operation to this level of sophistication, you can really save time in code review.

Aggressively Automate Code Review

Hopefully this gives you some ideas for the types of activities you can automate.  I can’t possibly cover every opportunity for automation in your code review process because I don’t know exactly what you check for.  (And even if I did, that would probably make for a prohibitively long blog post.) Point is, you need to own this improvement process for yourself.

Toxic code review practice creates human and efficiency problems.  Morale suffers, meaning productivity suffers.  But even a cordial review process probably has many opportunities to cut manual waste.  To combat this, you need to aggressively pursue automation just as you would in any other area of the business.

So take what I’ve written here and expand on it.  Consider for yourself what sorts of automation opportunities exist in your code review process, and pursue ways to implement them.  And remember, when you automate code review feedback, you speed up the review — and you also speed up the team’s skill improvement that stems from the review.