...
- When you create your PR, you will assign someone to review it, based on who you think will do the best job.
- When you receive a code review request, show the courtesy of responding within a day on when you can complete the code review.
- You can't send people thousands of lines of code, limit your pull requests to approx. under 500 lines. This does depend on the language involved. This is a heuristic, not a hard and fast rule.
- You need to review every line of code. You should be able to understand the code.
- Provide feedback! Is the code expressive and easy to understand?
- Don't let egos get involved. Having a lot of comments is a good thing, this isn't about someone's code being criticized. It's about improving code readability, quality and finding bugs.
- In general, try to get your code reviewed every 48 hours.
- It's okay to have several code reviews in a sprint.
- It's okay to have several code reviews for a single ticket.
- If you are writing a lot of boilerplate code, you could drop more code in a single PR for review if desired, because the reviewer could learn the syntactic pattern.
- Don't hold on to your code until the issue is resolved, there is no need to do that.
- You can use Pseudo code and include your design, the code doesn't have to work. Comment it out if needed, because we don't want to break tests either.
- This is NOT an approval process, this is about having a conversation about how you should proceed forward, and is the code of high quality.
- It is harder to review code than it is to write it. Please write more comments and description outlining your work. Reviews take more effort - please write a paragraph about your code.
- Also if the person that has the context can't do your code review for some reason, the other person will have that much more context when performing the review.
...
{"serverDuration": 314, "requestCorrelationId": "3d33aaf5a691479a9296a4570657432f"}