What is a code review? and Why should they be a part of your process?
--
A code review is a standard practice in the software development life cycle, where one or more people review the source code of another developer. The goal of the review can vary, but it is generally to increase the code quality and provide consistency to a code base.
It is something I find many people have the hardest time adapting to when moving into industry and as developers moving through their careers. As an Engineering Manager, this is an area I find there is a very high probability of coaching employees. It is not uncommon for someone who is new to the process to submit their first review and have a large amount of feedback for various reasons.
#1 rule: This is about sharing knowledge and improving, not to catch someone out or shame them.
When I started writing code professionally, there were no tools to facilitate the process. We would literally call a meeting for any large or important pieces of code we were adding to the code base. All of the participants would manually review the code and give their feedback. Depending on the nature of the code, feedback could be given 1-on-1 or in a larger group where we would discuss the effect of the code on the code base.
Nowadays, we have built-in support for code reviews. They are often referred to as Pull Requests (PRs) and/or Change Lists (CLs), where the submission of the code is more than likely gated by a review.
Benefits of code reviews
Back in 2006, Jeff Atwood, co-founder of stack-overflow, wrote in his “coding horror” blog that “peer code reviews are the single biggest thing you can do to improve your code”. Since then, code reviews are now commonly used in most tech companies to help achieve the following goals:
- Better code quality: makes the code more readable and maintainable
- Finding defects early: when a bug is found early, it is cheaper to fix.
- Learning/Knowledge transfer: team members gain better understanding of the code base and learn from each other.
