Code Reviews: Setting Up Your Team for Success

When done right, code reviews can help make your team more successful through continuous feedback and improvement.

Code Reviews are an important part of our process at kohactive. They ensure quality code and help our team members grow as developers. Although code reviews might take some time to implement, your team should ultimately consider the important benefits that result.

"Code reviews take time. Why are they worth it?"

Save time and money!

It is easy for a developer to get tunnel vision while working on a feature for an extended amount of time. Are there use cases that were missed? Logic mistakes? Syntax errors? Having a second pair of eyes read over your code reduces the risk of issues the developer missed. This avoids bugs being pushed to production, which will save you time and money that would have been spent on fixing them.

Grow stronger developers

Junior developers or new team members learn best practices during the review process, both as the reviewer and the author. The reviewer may find a different solution than they might have taken to create a feature, fix a bug, or learn some new technology. The author receives feedback to write more efficient and cleaner code. Reviews allow developers to share their knowledge with one another.

Avoid Bottlenecks

Team members may not work on all parts of an application, but reviewing another developer's code for other parts allows them to become more familiar with the rest of the codebase. This avoids one person becoming the only resource available when a bug arises. It also allows the developer to discuss solutions before building a feature with their teammates and the teammates having sufficient knowledge of the whole codebase.

"We want to add code reviews to our process. Now what?"

To get started with code reviews, it's important to lay out some ground rules for the process. Each organization is different, so it's essential to find a process that works for you. At Kohactive, we've outlined our code review process and guidelines in our playbook. Here are some tips for starting your code review process.

Add your Reviewers

At kohactive, we add at least two reviewers to our pull requests (PR) and require at least one approval before merging the PR with the upstream branch. At least one pair of eyes on the code ensures quality code before merging.

Provide a detailed description

Make it as easy as possible for the reviewer to look at the PR and understand exactly what you are trying to accomplish and the steps you took to get there. Let the reviewer know if there were any troubles and why you took the steps you did to surpass them. All of these details help them understand what they are reviewing. It also prevents them from skimming the code for small errors because they do not understand the objective, and allows them to give more insightful feedback to the author.

PR size: smaller is better

Try to keep your PRs concise and focused on one feature or fix. This helps the author stay focused on the logic of that one thing. If too much is put in the PR, the author can lose focus, find it overwhelming, and end up skimming the code.

Inspect the code

When you are assigned to review a pull request, make sure you do more than just look for syntax errors. Although those are important, you want to make sure to take a deep dive into the code to understand the logic and make sure the functionality works as expected. This most likely requires you to pull down the code from GitHub and run it locally.

Some things to look for while reviewing code:

Quality Code

  • Is the code efficient in both memory and time?
  • Is there a better way to handle the logic?
  • Does the code cover all error/success cases?
  • Are there any potential security issues?
  • Is the code clean of any unnecessary logging statements?
  • Are there tests and do they pass?
  • Is the developer using the following two principles?
  • DRY Do not repeat yourself
  • KISS Keep it simple, stupid

Maintainability

  • Is the code easily maintainable?
  • Are there parts where the developer could turn their code into reusable functions or components?
  • Are there comments or documentation when necessary to help future developers understand what is going on?

Readability

  • Is the code easy to understand by just reading it?
  • Are the variable and functions names representative of what they do?

Style

  • Does the code follow the team's styleguide?

Review your code!

Developers are humans, and like all humans, they make mistakes, forget something, or miss a detail. Having a second pair of eyes helps catch these mistakes and is an easy way to ensure quality code.

Don't just create PRs for PR sakes. Make code reviews a part of your team's process as soon as possible. The time spent now kicking off this best practice will benefit in the long run. Your team will grow as developers, spend less time fixing bugs, spend more time building new features. As a business, that means saving a lot more money.