All good developers in an agile environment want to consistently write better code review. While there will always be inevitable bugs, the goal is to keep them to a minimum. At Zibtek, we believe it’s more efficient and effective to build quality into the product as we go, not test the finished product to identify and fix issues. So, we use what’s called peer code review, a process where team members check each other’s code for bugs and mistakes.

Why Peer Code Review?

Peer code review has been shown to accelerate and streamline the software development process as few other practices can.

Traditional vs. Peer Code Review

The traditional code review process is not particularly well-liked by agile project teams. First, agile teams are self-organizing, which means skillsets span across the group. In a standard code view, the process falls to one person, typically a senior Dev or team leader. That’s a problem for someone on an agile team because:

  • It’s tedious and not considered a fun task.
  • The work takes a lot of time for one person, tying up precious time from senior talent.
  • Most senior engineers don’t like code reviews. They prefer things like architecture and writing software.

Companies that use a traditional code review process often end up losing top talent who aren’t interested in devoting their time to what they consider to be less fun work.

The Zibtek Peer Code Review Process

Everyone handles peer review a little differently. Here’s how we do peer code review process.

Zibtek’s peer code review has more people involved in the code review process, but we don’t throw the work at newbies. We let people get to a certification spot, say six months or so, where they know the product and its features well enough that we believe they can handle peer reviews. It’s a bit like a graduation, with them getting past the learning curve. It also protects the product.

During the peer code review process itself we:

  • Look at the coding standards, which often contain up to a hundred items.
  • Prioritize five that we really want to improve.
  • Make sure the person doing the review fully understands the type of code they’re reviewing. We want to avoid turning the peer code review process into a mentoring or training operation, which can increase the amount of time it takes to complete the task.

Two of the greatest benefits peer code review brings to the table is it:

  • Facilitates knowledge sharing and exposes Devs to new ideas and processes that help them write better code.
  • Cuts the per-code review time down to about 15-20 minutes.

People often ask how peer code review fits in with continuous development (CD) and DevOps. Doesn’t it extend the project’s end date? Done right, peer code review actually saves time in the long run. We still have CD and DevOps set up, we just set a trigger or manual stop in there where we want to do the peer review. Once the peer review is done, it’s a simple click to continue with the build.Want to learn more about peer code review and how it guarantees a higher quality code base? Contact Zibtek online today or call us at +1 (801) 895-2894 to schedule a consultation.