Cesar AguirreCode reviews are a great tool to identify bugs before the code head to the QA team or the clients. Sometimes you need another pair of eyes to spot unnoticed things.
Also, code reviews are great to keep the code clean as the project moves forward. They help to spread knowledge inside a team and mentor newcomers or juniors.
But, it's true that code reviews can be terse and frustrating for the reviewer and the reviewee. No worries! Here, you have a collected list of tips and tricks for better code reviews.
TL;DR
- For the reviewer: Be nice. Remember you are reviewing the code, not the writer.
- For the reviewee: Don't take it personal. Every code review is an opportunity to learn.
- For all the dev team: Reviews take time too. Add them to your estimates.
What to look for in a code review?
What should I look at? Are you new to code reviews and you don't know what it's going to be reviewed in the code you wrote? Or have you been asked to review somebody else's code and you don't know what to look for? You can take a look at this:
Does the code...
- Compile in somebody else’s machine? If you have a Continuous Integration tool, you can spot if the code is compiling and all tests are passing.
- Include unit or integration tests?
- Introduce new bugs?
- Follow current standards?
- Reimplement things? Some logic is already implemented in the standard library or in a extension method?
- Build things the hard way?
- Kill performance?
- Have duplication? Has code been copied and pasted?
It's a good idea to have a checklist next to you while reviewing code. You could create your own checklist or start using Doctor McKayla Code Review Checklist.
For the reviewer
Before you start any review, make sure to understand the requirements. Start by looking at the tests, they should be like documentation. It's a good idea to look at the diff twice. One for the general picture and another for the details.
- Be humble: We all have something to learn.
- Take out the person when giving feedback. Remember you are reviewing the code, not the author.
- Be clear: You may be reviewing code from juniors, mid-level or seniors. Even from non-native speakers of your language. Everybody doesn’t have your same level of experience. Obvious things for you aren’t obvious for somebody else.
- Always give at least one positive remark. For example: It looks good to me (LGTM)
- Use questions instead of commands or orders. For example, Could this be changed? vs Change it
- Use "we" instead of "you"
- Instead of showing an ugly code, teach. Link to resources to explain even more. For example: blog posts and StackOverflow questions.
- Review only the code that has changed.
- Find bugs while reading the code, instead of style issues.
For the reviewee
- Don't take it personal. It's the code under review, not you
- Find in every review an opportunity to learn
- Make sure the reviewer have enough context to review the code. For example: write a description of your Pull Request. Include what it does and what decisions you made
- Keep your work short and focused. Don't make the reviewer go through thousand of lines of code in a single review session.
- Keep all the discussion online. If you contacted the reviewer by chat or email, bring relevant comments online
For team management
- Code reviews should be the highest priority
- Code reviews are as important as writing code. They take time too. Make sure to add code reviews to your estimates
- Have as reviewer someone familiar with the code being reviewed
- Have at least two reviewers. For example, pick one reviewer, then he will pick another one until the two of them agree
You may feel frustrated with code reviews, either as reviewer or reviewee. Sometimes, reviews could end up being a discussion about styling issues. I know... But, be humble and nice! Every code review is a chance to learn something new.
Sources:
