How We Do Code Reviews

We pride ourselves on exceeding customers' expectations by delivering state-of-the-art web and mobile apps that users love. Thorough code reviews are an important part of how we achieve that, as they allow us to ensure we're writing well-structured and maintainable code.

Though we practice continuous integration and regularly run automatic tests, human eyes are still crucial to making sure our code is of high quality and functions well. That's why code reviews are baked into our development process at sophilabs. We don't merge any new code into the main development branch until at least one other teammate has checked it over and we've made any necessary changes. In this post, we'll explain our approach to code reviews and walk through our process step by step.

Step One: Create a Pull Request

Whenever one of our developers finishes writing code for a particular functionality, they create a pull request (if they're using GitHub) or a merge request (if they're using GitLab) and assign this piece of code to a teammate to check over.

Ideally developers can ask the teammate who wrote the original draft of the code for that functionality to look over the new code that they added. When this isn't possible, a developer can assign the code review to whoever on the team is well-versed in the relevant programming language.

In cases where a solution involves two programming languages, a developer might choose to assign the code review to more than one reviewer depending on each teammate's breadth of knowledge and skills. A developer might also ask more than one teammate to check their work if the specific functionality they worked on is very critical to the software or if the changes they made are especially significant or complex.

Step Two: Receive Feedback

During this phase, the reviewer checks their teammate's work, looking closely at all changes. Not only do they make sure the code is correct, but they also test the feature to see if it actually works as expected.

GitHub and GitLab both have comment features that allow a reviewer to leave written feedback wherever they detect an issue. The developer can then respond to the reviewer's comments if they have questions. The developer and reviewer might also meet briefly in person if there are complex issues that are easier to explain in conversation.

At sophilabs, our rule of thumb is to focus on the work rather than the individual developer, especially when giving constructive feedback. We also find that the more specific the reviewer can be, the more helpful their feedback is for the developer.

Step Three: Make Changes & Review

In this phase, the developer makes improvements to the code. After that, the reviewer takes another look and either approves the changes or provides more feedback if there are areas that require adjustments. This collaborative process can go through several rounds until the code is in excellent shape and the reviewer approves the pull request.

We have rigorous standards for our code, and the joint effort that occurs throughout the review process has a positive impact on code quality. We're also team players, so we frequently offer to help each other implement changes, especially when a problem is tricky.

Step Four: Merge Code

The final stage is to merge the code into the main development branch. At sophilabs, we take ownership of our work: although we receive help and feedback from our teammates, we ultimately consider it our personal responsibility that our individual contributions to the software function properly.

Building high-quality software is a complex endeavor, and including code reviews as a mandatory part of our development process is just one way we make sure we're creating an excellent product. We think diverse perspectives make for better solutions, and we hold each other accountable for doing our best work.

At sophilabs, our main purpose is to develop software that meets our customers' needs, so we've designed practices that ensure client success. If you want to find out more about how we work, take a look at our development process.