Pull Requests and Code Review: Strategies, Techniques,and Best Practices for Collaboration

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