In “Stopping Bugs: Seven Layers of Defense,” I failed to list one of my favorite methods of stopping bugs: code reviews. Since I am hesitant to change the title of the original post to “Eight Layers of Defense”, this post supplements the original, adding another layer to our bug stopping arsenal. I would place this critical layer between Layer 4 (Unit Tests) and Layer 5 (Asserts).
Why perform code reviews?
One reason: studies show code inspections are a cost effective investment in preventing bugs from reaching our customers. See Ganssle [1] below. Additionally, continuous reviews using a modern pull-request based process are an excellent way to improve maintainability and prevent technical debt from piling up in our code base. I also find that code reviews help distribute knowledge of the system and underlying code amongst additional team members. This helps create a pool of pitch hitters when a key developer is on vacation.
How?
Many years ago before git and pull-requests, we performed dozens of reviews a week using nothing more than zip files, emails and scripting. It worked, but we lost years of metadata and wisdom to the never-ending flood of emails. Later, we switched to an early version of pull-requests in a Mercurial based revision control system. It too worked, although the code base in question pushed that particular system to its breaking point.
Thankfully, today’s teams may select from a plethora of solutions with robust pull request based code review systems (see [5] below) that are simultaneously integrated with case tracking systems as well as other “DevOps” based tools (see [6] below). In one of my consulting projects, a development team consisting of hundreds of developers contributing to millions of lines of code is now using a pull request based review system where the new code is run through a series of builds, static analysis steps, and automated execution of selected unit tests. If any of these automated checks fail, reviewers are notified and merging of the code is automatically denied.
There is certainly more to say on this topic, but the internet is already full of excellent resources on this matter. To learn more, check out the resources listed below. Then select a modern revision control system including pull-request based reviews. Next, develop coding standards and review check lists for your team to consider when reviewing code.
Finally, review every change, every feature, and every patch.
By-the-way, I love reviewing code: please see our related services.
Resources:
- [0] Seven Layers of Defense
- [1] http://www.ganssle.com/inspections.htm
- [2] https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
- [3] https://www.michaelagreiler.com/code-review-checklist-2
- [4] https://embeddedartistry.com/blog/2017/02/27/best-practices-for-peer-code-review/
- [5] https://www.atlassian.com/git/tutorials/making-a-pull-request
- [6] https://about.gitlab.com/devops-tools/
Thank you for this post Matthew.
My key take away is the mention (and reminder of importance) of the steps – develop coding guidelines and review checklist.
Helps a lot to make a new Developer in the team feel at ease understanding the codebase (common handwriting or so).
I was when being onboarded while working with you on that customer project in SF 🙂
Thank you again.