Nov 2, 2016

The Human Side of Code Reviews

Code Reviews are one of the most effective practices for keeping code quality high. They help catch bugs early, keep best practices for code style/quality, and share knowledge with co-workers.

Since code reviews involve multiple people being critical of someone’s work, negative emotions often come into play. The following are some suggestions on how to handle the emotions of a code review and effectively communicate with code reviewers.

Expect changes going in
Go into a code review with the expectation that changes will be needed to be made. For this reason, it’s best to get code reviewed early on to leave plenty of time for changes. Consider using alternative code review methods like screensharing if it helps you get feedback earlier.

Be your own first code reviewer
Before you even make a commit, review all your code changes using git diff or your favorite compare tool. Usually, you can anticipate suggestions people will make and correct them early.

Give reviewers context to your changes
Give a good description of the changes and link to the relevant task in the issue tracker. Add enough comments to clarify gray areas in the code. Some code reviewers may be starting the code review with very little background in the area. Making comments inline in the code review can also help clarify.

Deal with code review comments head on
Code review comments can provoke negative feelings since they are critical of your work. Don’t take comments personally. Most developers just want help improve the quality of the code.

Handle comments immediately, defer and document suggestions as a last resort
If you’re already under pressure to ship code, added code review comments might cause you stress. I find it best to deal with comments immediately to relieve any stress they might cause. Don’t defer fixing any code review comments that can be resolved immediately. If you must defer any code review suggestions, document them in code comments or your issue tracker for follow up.

Acknowledge every comment before closing a review
Replying to a comment communicates to reviewers that you have received and resolved the comment by discussing, deferring, or handling the feedback. This shows reviewers you appreciate their comment and encourages them to participate in the future.

Reviewers, give reviewees context to your comments
As a code reviewer, it’s useful to mention if the comment is out of scope of the changes being reviewed or could be handled later on. This will help relieve some pressure from the reviewee to complete other code review suggestions.

At the end of the day, remember that code reviews are a team process about making better quality software.

About the Author

Object Partners profile.
Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Android Development for iOS Developers
Android development has greatly improved since the early days. Maybe you tried it out when Android development was done in Eclipse, emulators were slow and buggy, and Java was the required language. Things have changed […]
Add a custom object to your Liquibase diff
Adding a custom object to your liquibase diff is a pretty simple two step process. Create an implementation of DatabaseObject Create an implementation of SnapshotGenerator In my case I wanted to add tracking of Stored […]
Keeping Secrets Out of Terraform State
There are many instances where you will want to create resources via Terraform with secrets that you just don’t want anyone to see. These could be IAM credentials, certificates, RDS DB credentials, etc. One problem […]
Validating Terraform Plans using Open Policy Agent
When developing infrastructure as code using terraform, it can be difficult to test and validate changes without executing the code against a real environment. The feedback loop between writing a line of code and understanding […]