Not surprisingly, software development teams have a propensity to automate. ?After all, most of what we do involves automating formerly manual processes. ?Stop keying that data in by hand! ?Let’s write a script that loads it automatically.
As software developers, we thus become connoisseurs of automation opportunity. ?Come on. ?Tell me you’ve never wandered around your office, observing others’ inefficient workflows. ?If you didn’t have a ton of things to do, you’d write a shell script that blew their minds. ?They’d have so much free time on their hands that they could take up knitting for part of the day.
But typically you don’t do things like this. ?You have more important things to do, like build software for your customers. ?And this hints at an intuitive sense of priority among software groups. ?You understand that you could?automate all sorts of things but that you only?should automate certain things. ?Adding a critical feature to the software you sell takes priority over automating George’s weekly email about fantasy football.
At least, that works for everyone else. ?And yet we have a surprising blind spot when it comes to ourselves. ?In some cases, we quixotically look to automate everything we might ever possibly do more than once. ?XKCD once captured this nicely. ?And then, on the flip side, we sometimes fail to recognize things in our own workflow that we could and should automate.
Code review definitely qualifies in this latter category. ?We seem to think of it as inherently manual activity, often ignoring the possibly of automated code review.
Aggressively Seeking Automated Code Review
In the title of the post, I mention?aggressively pursuing automated code review strategies. ?Bear in mind that aggressive does not mean reckless, nor does it mean automating without considering ROI. ?You don’t want to fall on the wrong side of that XKCD chart.
I’m talking instead about aggressiveness in auditing your activities for automation opportunities. ?Any time you spend on manual activities is time that could theoretically be automated. ?Are you critically examining all of that time, or do you have activities that you assume must happen manually?
When I talk about aggressiveness, I’m talking about considering nothing in your manual process as sacred. ?You should keep your eyes open for tools or techniques that can save you time, making your manual reviews more critical and your process more efficient. ?Let’s talk about some examples of those opportunities.
No-Brainers and Low Hanging Fruit
First of all, you have some really simple things you can do. ?You’re already receiving a form of code review from sources that you might not expect.
Go do a build of your code and see if you get compiler warnings. ?If you have compiler warnings, you’re failing a code review?from the compiler itself. ?You can automate a fix for this issue by opting to treat compiler warnings as errors. ?Now nobody can fail the compiler code review and run their code.
Similarly, you probably have some kind of automated test suite. ?These provide another form of out-of-the-box review of your code. ?If you’re making these things fail, you’re failing that review.
Don’t waste time at code review arguing about which compiler warnings are bad or how it could behave at runtime. ?Automate those checks.
Use Formatting/Linting Tools to Handle Cosmetic Concerns
Let’s assume that you’ve started listening to your compiler and unit test suite. ?You still have another relatively easy opportunity. ?Find a tool to check or even automate formatting for you.
Over the years, some of the least productive moments I’ve seen during code reviews concern formatting. ?You didn’t add an underscore in front of that field name. ?You should use pascal case instead of camel case for property names. ?Or maybe you forgot to add some proprietary name-encoding scheme. ?The specifics don’t matter.
What?does matter is how easily you could automate these sorts of checks. ?At the very least, get a tool that flags violations. ?Better yet, get one that corrects them automatically. ?If you’re discussing this stuff at code review time, you’re not pursuing automated code review aggressively enough.
Use In-Editor/IDE Tools to Check Best Practices
Moving on, let’s consider fruit hanging a bit higher in the tree. ?I’m talking now about substantive review points.
Remove private methods that no one uses. ?Don’t swallow exceptions with empty catch blocks. ?Avoid returning arrays in properties. ?All of these items could and should come up during manual code reviews when code runs afoul of them. ?And yet all of these represent situations for which a tool can easily check. ?And if you’re serious about automated code review, you’ll avail yourself of such a tool.
When you leave this as a matter of manual review, it forces everyone on the development team to memorize laundry lists of language best practices. ?And while this ultimately makes them better programmers, it’s hardly efficient or bulletproof. ?Things will slip through the cracks.
But when you automate, nothing slips through the cracks. ?Even better, the team learns faster. ?The tool in their IDE will tell them about mistakes right away?instead of a week later at code review time. ?The code will look better and team members will learn faster.
Make Use of the Build and Gatekeeper Schemes
All of the schemes I’ve touched on so far will help, and immensely. ?But to some extent, they still rely on individual diligence. ?People have to treat warnings as errors locally, and they have to check the linting and code review tools of their own volition. ?Most likely they’ll do so, and gamely. ?But they might forget from time to time.
Just as you can automate angles of review, you can also automate enforcement. ?Take the tools that developers run on their machines and incorporate them into the team’s build. ?If the code doesn’t have proper formatting or runs afoul of the review rules, you can fail the build.
You can get even further out in front of things. ?Try using a gated check-in?to prevent developers from committing non-compliant code in the first place. ?At first blush, this may sound harsh. ?But it’s actually a lot less contentious to fail some automated process and make a correction than it is to sit in a room and listen to people tell you that you did it wrong.
If you automate both the checks and the enforcement, you make it?impossible?for people to fail these automated checks. ?This makes for better code and for time better spent during manual review.
Get Creative
I’ll leave off with a final piece of advice. ?Throughout this post, I’ve offered some standard techniques, approaches, and types of tools that you can use to automate code review. ?But I can’t possibly know everything you do or cover in your manual code reviews. ?You’ll have to apply this thinking to your own situation.
Think of when you wander around the office mentally cataloging automation that could help others. ?Apply this same mindset to your code review, initially tossing out any constraints. ?Assume that you can automate?everything?about it, and then discount possibilities only when you realize they’re prohibitive. ?The more creative you get, the more time you’ll save, and the more valuable both your automated and manual code review processes will be.
Learn more how CodeIt.Right can help you automate code reviews and improve the quality of your code.
1 Comment. Leave new
[…] Automate it as much as possible to minimize the subjective human element. […]