At Brightspot, our code pull requests are regularly required to be reviewed by either a peer or senior developer. I thought it was just a routine check for bugs. However, many months later, as I switched between the roles of a developer and a reviewer, I realized that code review is really more than just a bug-check. The code review process is critical for the success of coding projects and has enabled me to become a more skilled developer.
Here are five reasons why I’ve found code review to be essential for ensuring the robustness, consistency, and sustainability of a coding project.
Image credit: Giles Ashford
Consistent design and implementation
Code peer review can enforce a consistent coding style throughout a project, thereby making source code readable by anyone who might be introduced to the project at any given time during development. One project may have several development phases, each of which could be distributed to multiple developers. If each developer has their own distinctive coding style and adheres to it, the project will inevitably become disjointed. No matter how well each developer plays their part, it would become challenging for others to efficiently insert themselves into the development process.
Using the review process to ensure consistent design and implementation also contributes to the maintainability and longevity of the software. It’s inevitable that changes will need to be made down the line, so it’s important you’re thinking about who will be responsible for making those changes. Will the same developers be in place when those code adjustments are needed? Will the project grow and new developers need to be added and brought up to speed? In the code review process, these factors need to be kept in mind. Later on, it will save you and the team valuable time, allowing you to focus on innovating the software instead of figuring out how the code works (or doesn’t work) together.
Ensuring project quality and meeting requirements
The scope of any given software project and its requirements might run through the hands of several developers. The code review process can serve as a check and balance against different interpretations of that scope and requirements compared to the code that ends up being delivered. The second set of eyes can ensure you don’t fall into the “pit” you created based on your own understanding of what is being asked and that something important hasn’t been overlooked. Having code scrutinized by your peers can save a lot of time “confronting” QA later on.
Improving code performance
Due to the lack of experience, some younger developers might be unaware of optimization techniques that could be applied on their code. The code review process provides an opportunity for these developers to acquire skills and boost the performance of their code. Additionally, it gives these younger developers a chance to hone their skills and become experts in their craft.
While realizing the required functionalities, many developers also try to pursue optimized code for conciseness and performance efficiency. However, this will result in more code complexity and less readability. (Note: Code conciseness doesn’t mean its logic is simple to understand.) Moreover, the data model that the code is built on might change in later development phases. Thus, such premature optimization will eventually increase the cost of maintenance.
Sharing new techniques
During a code review, developers can also share new technologies and techniques with each other. Sharing techniques transcends seniority, where every developer is equally able to share, cooperate and improve their skills.
Whenever I receive feedback from my colleagues, I prefer to review them in a timely manner. Typically, I understand where problems are and fix them directly. When there are situations where I get confused, my peer reviewer helps me obtain the appropriate solution. The code peer review process is able to gradually broaden my skill set and ensure the quality of our projects.
On the other hand, we look for techniques and methods to automate the peer review process as much as possible and save everyone time. For example, to save time on compiling and deploying, we introduced the Travis CI tool. Once a pull request is initiated, the github can synchronize with the Travis CI and tell if the build is mergeable. Subsequently, the Travis CI will build the PR and update the status on github accordingly so that developers can conduct the merging in a timely fashion.
Though we work to automate the code review process, not everything can be automated and manual testing is sometimes more efficient and thorough. Recently, our delivery team found an alternative and better workflow to merge pull requests. After code reviewing, we first deploy the requests to a QA environment and test features, rather directly merging the requests. Only if all test cases are verified, the pull request can be merged into the develop branch. This new workflow keeps us from reverting buggy commits and makes our development branch more robust.
My experience with the code peer review process at Brightspot has enabled me to become a better developer, both as a code reviewer and as the employee receiving code peer review. Not only does this process help make me a better developer, but it ensures the long-term success and proper development of our product, Brightspot.
Minimizing your mistakes and their impact
This might seem like the most obvious advantage to the code peer review process, but it’s also one of the most important. When you’re working with the real pressures of time and budget, it’s easy to skip this step. Sure, you’re confident in your work, but even the best coders can go crossed-eyed from looking at their own work too long. Code review helps give a fresh set of eyes to identify bugs and simple coding errors before your product gets to the next step, making the process for getting the software to the customer more efficient.
Simply reviewing someone’s code and identifying errors is great. However, when it comes to the code peer review process there also needs to be a level of follow-up and accountability. Make sure there is process in place for checking back in to confirm code discrepancies have been addressed before moving into production.