Code reviews (also referred to as Pull Requests popularized by Git) are tools for software engineers to maintain a healthy balance of mentorship, teaching, and code design. If done right, a team can grow other developers and enforce specific standards as the code base evolves.
What are code reviews?
A code review is a common part of many team processes. The idea is that once you finish a coding change, you must have it reviewed before the change is accepted into the general code repository. Peers can do the review on your team or domain experts who are familiar with the code. Also, code reviews will allow others to become familiar with your code and use their experience to improve your code and help you learn and improve.
The code review process can be scary for some, especially early in your career. If you have a strong supportive team, the code review is an excellent way to learn from others. It offers a form of mentoring and knowledge passing from senior members of the team.
The primary value code reviews will ensure adherence to a specific architecture, design, naming, and other domain standards that far outreach the simple ability for a developer’s coding chops. Therefore, getting many comments or questions on a code review does not reflect negatively on you as a developer.
You should not expect it to be used as a buffer for catching bugs, though. Often analysis and review of the code can still allow subtle and destructive changes, so do not consider a code review as a substitute for testing your changes with the product by manual and automated testing (such as unit, integration, and full end-to-end tests).
When used effectively, it allows sharing your proposed changes in a collaborative environment. It will allow others to see things you may have missed (such as not checking for nulls or not logging an error), give diverse ideas on how to solve things, and allow experienced developers to help catch gotchas in the code (whether it is domain-specific or general design pattern specific).
Tools to help code review
Many established tools help with code reviews, and you will save a lot of time by using those. Many bigger companies such as Facebook, Google, and Microsoft have built their own proprietary code reviewing systems. One common public offering many may be familiar with is the Pull Request Review System built into GitHub. One of the favorites that I’ve used is Microsoft built (similar to Github but better in my opinion: Azure Dev Ops.
Importantly, keep code reviews centered around engineering concepts versus repetitive nits on syntax. For syntax, many languages and build systems can use automated “linting” for the codebase. Linting helps automatically enforce syntax or common anti-patterns that are easily detectable via tooling. For example, a good auto linter for Javascript is Eslint.
Guidelines to help author code reviews
- Keep code reviews concise and targeted at addressing one thing. Try to keep code clean up, refactors, new code additions, and bug fixes separated into different reviews. Big reviews will take longer to review, and expect the reviews to be of less quality.
- Suppose you find yourself with a large code change that needs reviews. It would be best to hold a meeting with your peers to walk through it. Even just at a high level, the discussion will help those reviewing your code understand the intent’s bulk. Respect your team’s feedback and split the code down into separate reviews if needed.
- If you find the team is asking to “nit” certain syntax issues often in code reviews, push for automated linting. These are wasting time on reviews when there is tooling available to automated the task.
- Take feedback light-hearted, and don’t be defensive. Being defensive can quickly turn good intentions into negative experiences. Understand it takes time and commitment for others to review your code and offer advice. Be respectful and understand their point of view. Sometimes the reviewer might be wrong, and that’s okay. Above all, having positive discussions will reflect on you, and the reviewer will continue to help you in the future.
In conclusion, the code review is an effective communication method for engineers to establish their code change ideas. If your team is strong, they will help each other grow and not judge you for making mistakes. Everyone will make mistakes, these tools allow those mistakes to be mitigated with more diverse thought and less time wasted.
For more thoughts on improving code design for yourself or your team, refer to this article to understand the importance of code design.
