I heard in a podcast position of one lead developer about code review. He stated that he doesn’t see much sense of doing PR review after 3-4 times since a new person joining the team. Reasoning was that if they hire a developer, they assume that these number of PRs with comments will be enough for this person to understand the code style and standards of the team. And after that code review is not valuable anymore.
Every team decides what better works for them, but my experience shows that code review is not about telling others how to properly write this or that line of code, and to hope that they will always follow these rules, it’s much more than that.
Why constant code review process is so important for a team?
- It’s a natural way of knowledge sharing between teammates. This can be valuable both for a reviewer, who sees something new in the PR, and for a PR owner who can learn from comments;
- It embraces team communication and debates about coding standards, best practices and it make team aligned on made decisions;
- It improves code quality and reduces chances of bugs. Two heads are better than one.
As any other communication, code review can be hard.
Some basic rules to make this process better:
- Respect. Express your feedback in a polite way, use questions instead of orders. Don’t make comments personal;
- Constructiveness. Provide some proving examples/sources for your suggested improvements. Try to be objective, rather than expressing some personal preferences;
- Positive attitude. Be helpful instead of judgemental. Compliment good things which you see in PR;
- Effectiveness. Provide clear unambiguous messages. If you see repeated pattern of some mistake, don’t put bunch of comments, just make a general one.
If you are a reviewer :
- Review the assigned PR as soon as you can;
- First check that build and all tests are passing and there are no conflicts. Don’t start review if some of these requirements are not met;
- Read the story description to understand the business logic and to acceptance criteria. Check the code against these criteria and continue to review only if business requirements are met and working correctly;
- Make sure that requirements are tested and edge cases are covered;
- Check the code style and make suggestions on how to make it clean. Better to do this on the latest stage, as during the previous ones your comments could cause code changes, and you would not want to review the cleanness of code several times.
If you are creating a PR:
- Include description of provided changes;
- Reply on all comments provided by reviewers. Reply as soon as you can;
- Don’t get offended. It’s not a critics, it’s a feedback. If you don’t like the tone of comments, just mention it to the reviewer. But care more about the content itself;
- Consider it as an improving point and try to learn from your peers. Appreciate their useful suggestions and be grateful for gained knowledge.
Happy PRs! 🙂