Pinpoint Networks

Feb 6, 2020

What best practices does your team follow when doing code reviews? Because of SOC 2 compliance, we must do things like lock down merging into master and ensure that all pull requests (PRs) have approval. If there’s an approval but a new commit comes in, we revoke the approval and start over. Apart from those strict, compliance-related processes, we try to have three reviewers with at least one reviewer running the code. We also try to be cognitive of the PR review load and make sure not one person is burdened with a ton of PRs a day. GitHub has a new round-robin feature for this but we haven’t implemented it yet. By doing this, we get the added benefit of knowledge-sharing and awareness around code changes in the product. When there’s a difference in opinions about how to write certain code, how does your team handle it? Visibility, collaboration and efficiency are core values. If there’s a new approach to some code, architecture or pattern, someone will usually prototype it out and share it with the team for feedback. This allows us to agree upon the right approach quickly. As the saying goes, “a prototype is worth 1,000 meetings.”   For example, we recently switched to React’s Router component. Some were skeptical that React Router met every single one of the requirements we had. Rather than make assumptions, someone on the team prototyped it out and demonstrated how it would tackle some of our advanced use cases. We reviewed it as a team, got quick consensus and made the pivot. For smaller, code-level reviews, the reviewers can usually come to an agreement in the PR or after talking it out in person. Ultimately, the tech lead on the team has the final say. Analyze and scrutinize the code, not the person.’’  What advice do you have for fostering a positive code review culture? Analyze and scrutinize the code, not the person. Make sure PRs are spread out among the team. Encourage team members to label nitpicky things as such, so it’s clear what’s minor, versus what is an important code critique. Enable the team through tooling for quick review. For example, on the front end, Zeit or Netlify do PR previews of a build that improves velocity. If you have to spin up an entire stack for every PR, it can discourage a good PR review.