番茄社区

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鈥檚 inevitable that changes will need to be made down the line, so it鈥檚 important you鈥檙e 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鈥檛 work) together.

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鈥檛 fall into the 鈥減it鈥� you created based on your own understanding of what is being asked and that something important hasn鈥檛 been overlooked. Having code scrutinized by your peers can save a lot of time 鈥渃onfronting鈥� QA later on.

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鈥檛 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.

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.

This might seem like the most obvious advantage to the code peer review process, but it鈥檚 also one of the most important. When you鈥檙e working with the real pressures of time and budget, it鈥檚 easy to skip this step. Sure, you鈥檙e 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鈥檚 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.

Join Our Team

Interested in software-engineering careers at Brightspot? Visit our careers center to see open positions and learn more about what it's like to work as a developer on our team!

See Current Openings