Code reviews are not just a great way to ensure code quality, they're also a way to build standards, mentor people and learn from mistakes.
Here are a few tips that can help a team in building an effective review process.
The longer the PR, greater the chance that parts of it will be overlooked. Small and frequent PR reviews create a better feedback loop.
Break down big stories into smaller chunks which can be developed and reviewed independent of the rest of the code.
Referring requirements and acceptance criteria makes it easier for the reviewer to understand the intent of the code. It reduces the need for synchronous communication during the review.
Include links to document or tickets in the PR description.
A PR should not have inconsistent code.
There should be no TODOs, unfinished methods, commented code or failing test cases.
Whatever purpose the PR solves, it solves it completely. Otherwise, it's not ready for review.
A team should maintain a list of guidelines that developers must follow while coding and raising PRs. It helps establish expectations early.
Before raising a PR, developers should refer to the guidelines and ensure they are followed. For e.g., these are some guidelines that should be followed while raising PRs:
- Code formatting
- Comment guidelines
- Variable naming conventions
- Unit test coverage
Use static code analyzers to validate PRs rather than having the reviewer decide if the code stinks or not.
Reviewers should focus more on business requirements and rules that are specific to the project.
Use code quality checks in the build pipeline to break builds if quality or unit test metrics are not met.
It's important to make code reviews a learning process and not one person pointing out mistakes of the other person.
Reviewing and being reviewed is a great way to share knowledge and perspectives.
Write useful review comments which help the developer understand the 'why' behind the suggestions.
As a developer, take time to understand why the reviewer made a particular suggestion rather than just blindly accepting it.
Give everyone a chance to review code and give more developers a chance to look at each other's code.
It makes them comfortable in communicating with each other, distributes the review work efficiently and breaks knowledge silos within the team.
The language used in a code review should be positive and constructive.
As a reviewer, include positive comments if the code is well-written and well-commented.
Suggestions should be soft like, "can we try this?" or "I think this is a good idea".
There should be no rigid and commanding language like "do this instead". Any review comment should be open to discussion.
Thanks for reading. I hope it gives you a few ideas on what to improve in your current review process. If you have some code review tips, feel free to add them in the replies.
If you want to connect with me, you can find me on Twitter