The Seven Ways to Review Code Like a Boss

07 Apr

From IT Business Edge

No software development practice improves quality, builds skills or reveals the best developers like the code review. It’s a critical process to examine software code in order to fix mistakes or find gaps that were overlooked in the development phase. Not only is it necessary to create the best quality and most user-friendly software – it’s a vital skill and learning process for developers.

The code review, or in developer parlance, the pull request, is the number one way to set the tone, rhythm and bar needed to build a high-performing team. Bugs are cheaper to address the sooner they’re found, and automated tests can find bugs and regressions. However, while automation can help check for known vulnerabilities, it 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. Developers who only rely on automated code reviews are doing their software and customers a disservice. That’s why manual code reviews are so critical to the development process.

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. In this slideshow, Ed Hintz, senior development manager at Bandwidth, has identified seven ways you can code review like a boss.

1) 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 priorities on that list should be 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 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.

2) 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 is, the better the code review will be.

3) Keep It Small and Frequent
Code reviews should be small and frequent — reviews that are 300 lines or less work best. 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.)

4) Pair Up Wisely
Code reviews are an excellent opportunity for 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. Younger or less experienced developers should be encouraged to speak up and ask questions – sometimes a fresh, eager eye can catch something a more experienced developer might accidentally overlook as part of their routine.

5) 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.

6) 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 resourceful patterns and techniques, while 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 comment on what 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.

7) Love the Code Review
Make the code review a valuable part of your development discipline, not something you have to do, but something you want to do. That’s how you 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.

Bandwidth
Bandwidth
dialed-in@bandwidth.com
No Comments

Sorry, the comment form is closed at this time.