Introduction
Create your PR before the code is ready for review
Review your changes from outside of your IDE
Document your progress
Make people want to review your PR
Make your PR small
Provide all the context needed for review
Make people trust you
Be your PRβs first reviewer
Adopt a different point of view
Anticipate any comment you could receive
Assign the right reviewers to your PR
Donβt assign your PR to the entire world
The more feedback the better⦠up to a certain point
Not everyoneβs feedback is equal
Use required vs. optional reviewers
Be responsive to comments
Be open to feedback
Fix what you can as soon as possible
When a comment isnβt clear, ask for more information
If you donβt agree with a comment, say it (with respect)
Always respond to comments
If you want people to review your PRs, you have to review theirs
You can review code even if you are a junior developer
Read the code carefully and learn from it
Speak up if something isnβt clear
Share alternative perspectives
Check the right things during code review
Learn from the code
Ensure good practices
Check for bugs or edge cases
Challenge the implementation
What code review should not be used for
Use the right tone in your comments
Use βwhy notβ instead of βyou shouldβ
Be open and positive
If you think something is wrong, suggest an alternative
Be clear about whether a change is required for you to approve the PR or not
Some comments require a change
Some comments only suggest a change
Some comments donβt ask for any change
Review your review before submitting it
First pass: review each line of code
Second pass: review the big picture
Third pass: review your comments
Approve the PR when the submitter made all the changes you asked
Donβt forget about the PR after adding comments
Review the whole PR at once
Some conflicts canβt be solved in comments
Continue the discussion somewhere else
Involve a third-party
Use a meeting to find an action point
Conclusion