Reviewer Journey¶
As a code reviewer, you may give some comments or suggestions to the pull requests that you are reviewing. Giving feedback to others sounds not beneficial to you, but actually, it can help you improve your soft skills like communication skills and idea explanation skills and identify your blind spot on some concepts during explaining an idea. Also, good comments can help you build a good rapport with your peers and help the team build a solid codebase, and bring the team to the next level. Sometimes, you can learn some new ideas from your peers’ code and discussion. So, don’t be stingy about giving feedback.
Be polite and professional¶
During code review, avoid using “You” or “Your” to prevent giving people hard feelings. When leaving comments, you can try to use questions to ask the code author whether another approach will be better. Also, you should provide more information and examples to help the code author to understand your idea. Using this approach, if the code author agrees with you, the code author will change the code immediately. If the code author does not agree with you, you can start a conversation with the code author to understand why he/she does not agree. Remember, take care of your peers’ feelings, and don’t be too harsh.
Given that some items are just an improvement or nice-to-have, the reviewer can ask the code author to create a TODO item on the codebase and release the pull request first and clear the TODO item later instead of blocking the pull request to be merged.
As a code reviewer, you should try to review the code as soon as possible and unblock your peer from the pull request if your schedule is not tight and time allows.
Automate style checking¶
This is not really the responsibility of a reviewer but the whole team. To avoid subjective comments on styling issues, we should form some styling rules and get an agreement with the whole team about the coding standards and styling rules. After that, automate the style checking by using a linter plugin. We shouldn’t waste time discussing style issues in a pull request. So, the reviewer can focus more on the actual concerns rather than formatting.
