Code Reviews — A Daily Joy
Not every developer finds joy in code reviews. I’ve heard them called a necessary evil and a waste of time. Some developers view them with fear and loathing. Fortunately, I have never participated in a code review process that was a bureaucratic nightmare or treated as an opportunity for ridicule or mockery. While the primary goal of code reviews is to improve the quality of the code base, it is no less an opportunity for both the developer and the reviewer to increase their knowledge and sharpen their tools — and find a little joy.
…an opportunity for both the developer and the reviewer to increase their knowledge and sharpen their tools.
During reviews, I frequently obtain a deeper understanding of a language feature or business requirement, or discover cleaner syntax, or a novel way of approaching a problem. And the learning happens on both sides of the review. I love it when I start a review and open up a beautiful implementation that solves the business case in a robust manner. Conversely, I also appreciate it when a reviewer points out something I could have coded more cleanly or shows me a technique I was not aware of.
Having productive code reviews requires the proper environment. The focus of a code review should be on improving on the quality of the code base. It should be as frictionless as possible — a seamless part of the development process — and not a hurdle to be avoided or subverted. If there is paperwork required, checking the boxes will become the goal of everyone involved. The quality of the code base will become a secondary concern.
Our shop has a very simple and flexible process that exemplifies this. When a pull request is ready for review, the original developer moves the ticket into the Code Review column of our development board. When another developer has the opportunity, they review the request, making comments or change requests as necessary in GitHub. The reviewer and developer can continue to communicate via GitHub until the changes are made (or deemed unnecessary) and the pull request is approved. If there are multiple change requests or a fundamental question about the developer’s approach the two will get together (virtually if necessary) and work through the pull request until they are both satisfied with the code.
The process is simple, asynchronous, and transparent. This allows the team to maintain velocity while ensuring that all code in the system has had at least two sets of eyes on it. As the code repository maintains the history of changes and related conversation right next to the code, it is easy to trace changes and the reasoning behind them. They are not lost in a separate system (or spreadsheet!) far removed from the actual bytes in production.
Our environment supports additional and/or more formal reviews. The original developer or reviewer can request additional reviewers via GitHub, often bringing in someone with a specific knowledge of the feature or system. This is our standard practice for any change that touches authentication, authorization or anything security related. For complex or wide-ranging changes we will frequently schedule a formal review so the developer, reviewers, testers and another stakeholders can all participate.
The key, if unspoken, part of every process is the people involved. As reviews should facilitate discussion about the code, the attitudes of both the developer and reviewer are critical. Reviewers must not take an adversarial approach, nor should developers be defensive. Code reviews are an asset when everyone involved approaches them as an opportunity to bolster the quality of the code base and perhaps learn something.
Sometimes it stings a bit when a “clever” bit of code I wrote gets questioned during a review. But as clever solutions do not age well and often serve as a source of confusion, the review accomplished its mission. It surfaced a potential problem before the clever bits ever sullied the code base. The short term sting is soothed by the knowledge that someone (perhaps me) won’t be cursing my cleverness in the future.
In the proper environment, everyone can learn from the code review process. A well integrated process, focused on improving the quality of the code will facilitate communication and sharpen the development team. Open minds and a collaborative approach turn code reviews from something to loathe into a daily joy.
