Code Review Like a Boss

17 Mar

In my 15+ years of software management, I have found no software development practice that improves quality, builds skills, or reveals the best developers like the code review.  The code review or in git parlance, the pull request, is the number one way to set the tone, rhythm, and bar needed to build a high performing team.  We all know bugs are cheaper to address the sooner they’re found and automated tests can find bugs and regressions.  However, automation can’t tell you the code isn’t following best practices, looks like a big mess of spaghetti, or is going to result in a maintenance nightmare.  Since the code review is such an important practice, it’s worthwhile to find the most effective way to review code to maximize its benefits.  Here’s how to code review like a boss.

Be the Enforcer

The first step is to meet as a team to list the principles that should be enforced in the code review.  Core on that list are things like architecture rules, security, privacy, maintainability, error handling, deployment/setup work, documentation, best practices and patterns.  Code review principles are worthless if not enforced.  Encourage the team during code reviews to be hard core and strict about enforcing the principles, regardless of whose code they’re reviewing.  Code authors need to have thick skin and not expect code to get merged in or accepted on the first review.  My team was once referred to as the code review equivalent of that famous Seinfeld character that would say “No soup for you!” because they felt like it was “No merge for you!” every time they submitted a git pull request.  We took that as a complement.   I have found the best developers welcome the discipline and the entire team picks up their game when they know up front that their code will be reviewed thoroughly.

“Code review principles are worthless if not enforced.”

Keep it Interactive

No one said reviewing code had to be a boring read-only exercise.  Get the code on your machine, build it, run it, and poke at it.  If you’re doing the code review in person, the person reviewing the code should be the one at the keyboard navigating while the author of the code explains it all.  The more engaged the code reviewer, the better the code review.

Keep it Small and Frequent

Code reviews should be small and frequent.  Reviews that are 300 lines or less work best.  I have years of anecdotal evidence that this results in higher quality code that is also backed by numerous quantitative studies (like this one) that show that high churn changes result in higher defect density.  If there is a long running feature being done in a separate code branch for an extended period of time, then have small and frequent code reviews in that branch rather than having one big bang code review later. (The “bang” in big bang code reviews is your app crashing at some point in the near future.)

Pair Up Wisely

Code reviews are an excellent opportunity for the more experienced developers to teach developers that are new to the code base, language, or technology.  Therefore, make sure the right people are reviewing the code.  Of course, everyone needs to learn how to review code.  In this case, you can have multiple people review the code—just make sure an experienced eye is involved.

IMG_9469

What’s Missing?

The top code reviewers not only notice what’s wrong with the code they are reviewing, they also notice what’s missing.  Is all of the deployment code there?  Internal and external documentation updates?  Did that new environment variable needed to run the test get documented in the README.md?  This is an acquired yet invaluable skill that only belongs to the best code reviewers.

Review the Code Review

Code review tools that preserve the code review comments and dialog are a valuable learning resource for everybody.  New developers can learn new patterns and techniques.  Managers can see who the leaders and keepers of code quality are on the team.  When there is a retrospective on a service outage or bug, you should look at the check-in or commit that caused the problem as well as the code review comments.  Everyone involved in this code should ask how this issue was missed and how the team can prevent it from happening again.

Conclusion

Make the code review a valuable part of your development discipline and code review like a boss.  When you learn to love the code review, you will build software and services that you and your customers love.

To stay up to date on blogs like this one, sign up for email notifications in the right side bar!

 

 

Ed Hintz
Ed Hintz
ehintz@bandwidth.com

Ed Hintz is a senior software professional who has written code that has run on everything from nuclear submarines to the cloud and on many devices in between. Ed is passionate about building high performing software teams that love their craft and create amazing services for customers. Ed is the Director of Cloud Services Development and applies Lean Software Development principles to build the next generation communications platform as a service. Ed enjoys water skiing, kite boarding, and biking, but not all at the same time.

2 Comments
  • Magic Tricks Revealed
    Posted at 18:13h, 25 March Reply

    Woah! I’m really loving the template/theme of this blog.
    It’s simple, yet effective. A lot of times it’s challenging
    to get that “perfect balance” between superb usability and visual appearance.
    I must say you have done a excellent job with
    this. Additionally, the blog loads very quick for me on Internet explorer.

    Superb Blog!

  • Dialed In - The Bandwidth Blog | The Android Developers’ Quality Toolbox. One Dev’s Top Picks.
    Posted at 18:37h, 08 April Reply

    […] branch runs both the Robolectric and Calabash/Appium tests against any changes. This, along with code reviewing like a boss ensures that each new commit is thoroughly tested and meets our quality control […]

Post A Comment