by Mike Stone
TL;DR
Along with catching bugs and regressions, PR reviews are a high value-add to our clients and a source of continued learning for our team.
Background
When we write code for projects, it isn’t immediately pushed live. Instead, each chunk of work is submitted for peer review in a “pull request” (PR).
The Problem
We’re all human, and the code we write could have bugs, regressions, or sub-optimized queries.
The Solution
To increase the chances that we’re writing bug-free, optimized code it is vital that we get multiple sets of eyes on every bit of code that ends up on the production site. Therefore, when anyone on the team submits code in a pull request, a link to the PR is shared in the #pull-request channel of our Slack team along with the language(s) involved and a brief summary of the work. All engineers subscribe to the #pull-request channel and are expected to review a few PRs per week. When an engineer decides to review a pull request they react to the Slack post with an emoji to alert the team that the PR is being reviewed (though it is still encouraged that other engineers also review the work). Once a PR is approved by a reviewer on Github it is free to be merged.
The Outcome
Along with catching bugs and regressions, these peer reviews have been a great source for continued learning across the team. Both reviewers and the author of the PR have an opportunity to learn new languages, syntax, code patterns, and optimizations. Peer code reviews also help our team gain context across projects and provide a great benefit to clients who are getting help from the team as a whole, as well as the engineers dedicated to their project.