...
- Check daily that code reviews authored by your team members are getting done in time to be useful
- Help your team member's find suitable reviewers, either by advising on their expertise or their availability
- Encourage cross-team reviews so that we don't get too silo'ed - when appropriate
- Ensure your team member's aren't over-burdened with reviews. Help prioritize and distribute when needed.
- Surface issues to the larger group to improve the code-review process.
- Make sure reviews waiting for an external team have already been reviewed by someone from the team.
| Anchor | ||||
|---|---|---|---|---|
|
- Create reviews that are focused and concise. Be clear in what you are asking for in the review. If it's complex or you feel it might need some explanation, then it probably does.
- Add only change-sets that help your reviewer. If there are miscellaneous change-sets that also need to be reviewed, create separate reviews for those. e.g. your main work was to add feature X, and in doing so you noticed that a NPE was possible in some non-related function Y, separate those into reviews of feature X and improvement of Y.
- Keep the code/file count short and simple, a couple hundred lines of code is better than 1000. Generally reviews should be 500 LOC or less. If the code is more complex, it should be shorter, and only if it is truly trivial may it be longer.
- Choose reviewers that are appropriate for the review. e.g. someone that has more experience in a relevant section of the code, or someone whom you'd like to potentially learn from. Ask a Team Lead for guidance and seek to break team silo's by finding a reviewer in another team or organization.
- If you are requesting a review from someone external to your team, it's a good idea to first have someone from your team review the code. This is to ensure that trivial issues are identified as soon as possible, making the overall length and the number of review iterations shorter. This is especially important if there's a huge time zone difference between the teams.
Link to any relevant work issues / stories that may help the reviewer with context.
Set a due date of no more than 2 working days into the future. If you need feedback sooner than that, work with your Team Lead.