<aside> ☝ This guide walks through the philosophy of why we conduct code reviews, and princples when reviewing other people's code.

</aside>

Philosophy

Code reviews have become a standard in programming, with the main purpose being to catch bugs and prevent breaking the code base. However, there is a lot more to code reviews than just this. Conducting code reviews contributes to many high level goals.

• Keeping code standards high for our entire organization. With code reviews, we are able to ensure that all code in our code bases has been seen by at least two people, and ensures a high standard for our product development.
• Investing in our engineers to be product conscious. With code reviews, engineers are able to review their code and keep in mind how it fits into the repository. This high-level vision helps them keep the product vision in mind and be more intentional with how they communicate.
• Mentorship. Code reviews offer an opportunity for mentoring engineers who are new to the tech stack, and walking through good engineering practices. It also opens the opportunity to walk through the different parts of the project and how they work together.
• Project visibility. This is unfortunately an underutilized benefit of code reviews. Code reviews provides the opportunity for more of the team to engage with other parts of the project and see what other members of the team are working on. For example, someone who is working on frontend has the opportunity to review code that is written for the backend.

A lot of time is spent in code reviews, so let's break down what makes an effective code review.

Communication

At the core, code reviews are just a method of communication. Be mindful of the language you use and how you convey your ideas. Be encouraging, and offer alternative ways on how to implement features with links to examples and documentation.

Also, remember that the GitHub pull request page is only the medium for a conversation. If you feel it would be more effective to have a conversation in person or over the phone, opt for that. It will be easier for both sides, and much easier than going back and forth with GitHub comments.

What to Look For

There are a couple things to look for while doing code reviews. The obvious ones:

• Code style. This will generally be enforced through the linter, but try to keep variable names descriptive and consistent.
• Bugs. Test the code yourself, especially if its not something that can be tested with continuous integration (such as a design change).

Less obvious ones:

• How well does the code fit into the repository? A good example of this is when an engineer writes a utility file for a feature that they are developing, but the utility file can be super useful for the other aspects of the project as well. Understanding how to surface functions like these can save a lot of time for future development.
• Repeated code that can be abstracted. Another simple example is when an engineer puts <Nav /> on top of every single component returned, rather than on top of the <App /> component (where it will persist across any component). Small changes like this has high impact.