Code reviews can help to improve the quality of code, reduce technical debt, and they are a great way to spread knowledge about the past, present, and future of a software project. The only problem is that code reviews will become your bottleneck. Here's what you can do to help others to review your changes much easier and faster.
1. Review’ pull requests of others
From my experience doing code reviews for over a decade, this is probably the most effective way to get your stuff reviewed quickly. It’s also a great way to level-up your understanding of the codebase and familiarize yourself with new methods from other developers.
2. Be your first reviewer
Nothing is more annoying than spotting spelling mistakes (my specialty) and other obvious mistakes in a code review. Before requesting a code review, review your own pull request with fresh eyes. This is also a good time to apply the next tip.
3. Add comments on your own pull request
Doing a proper code review takes time. Therefore we should make this a pleasant experience for everybody. Use review comments to guide the reviewer through your changes. Think about what may be unclear to them and provide additional context.
4. A well-drafted description
Do not copy the JIRA ticket description. Instead link to the ticket, (this can be automated using Pull Request Badge) and write a description for your peers. For visual changes, it’s helpful to include screenshots (before, after) or record a quick video. Adding links to visuals, mockups also help reviewers to get a better understanding of your change.
5. Specify the area you want feedback on
Specify the areas you want feedback on. Are you concerned about a specific line of code? Are you looking for alternatives? Adding this background helps the reviewer to provide more effective feedback.
6. Credit
Post any interesting findings which you came across while researching for a solution, such as documentation or blog posts. Also, don't forget to include a link to the Stack Overflow posts where you copied the code snippets from.
7. Automate nitpicking comments
When someone asks for trivial changes, consider automating such feedback into your CI. Tools like Danger or ESLint can help. Btw, writing a custom ESlint plugin is not that complicated.
8. Split your pull request
Don’t be afraid to put the extra time into splitting up your work, it's worth it. For example, if your change includes a refactor, create a separate pull request just for that. Not only does it make your main pull request smaller, but it also allows others to enjoy your improvements without being blocked by the other change. Also, it will go into production earlier, and therefore provide confidence in the change.
9. Close pull request
If you took the wrong route, close the Pull Request and open a new one. Point to the original and explain why one approach was chosen over another. Your future self will appreciate that over a force push.
10. Gangsta merge
Let’s end with a controversial one: Not every Pull Request needs code review. Sometimes it's totally legit (in my opinion) to skip the formal code review process if
- a super trivial change is being made, such as updating an image
- obvious spelling mistakes are being fixed
- a hotfix needs to be applied to a production as soon as possible to avoid further damage.
Do you have other tips on how to improve the code review process? Share it with me — I’m @buckstefan on Twitter.
Top comments (1)
great piece of advice! thanks for sharing!