How to do great Code Reviews?
This is a summary of different blog posts related to Best practices around Code Reviews by Molly King.
There are three parts of a Code Review:
- You review your own code before you create a PR
- You review someone else's code after they created a PR
- You have your code reviewed by someone else
Reviewing your own code
Always run your code and make sure it works before you create a PR. Make use of linters to adhere to your teams' standard. Read through the diffs that you created and compare your changes to the ticket you worked on. Do they cover everything or do the go beyond? If so, maybe split the work up into an additional PR. Are your variables and function names properly named? At some point in the future someone else will have to take care of your code.
Reviewing someone else's code
- Be empathic with your colleagues' code
- Be sensitive
- Something might seem simple to you but that doesn't mean that it is obvious to them, so make sure to provide additional information. Avoid filler words of just / simply
- Prefer writing open ended questions over demands.
- Focus on sharing knowledge through Code Reviews
- Keep a positive attitude
- Treat reviews as a teaching opportunity
Having your code being reviewed
- You are not your code. Don't have too much ego and take critique personally
- Clarify and communicate
- Address pointed out issues
Better Code Review, Part One
Better Code Review, Part Two
Better Code Review, Part Three
Frustration Free Code-Reviews
On Empathy in Software Engineering