Effective Code Reviews
?? Saral Saxena ??????
?11K+ Followers | Linkedin Top Voice || Associate Director || 15+ Years in Java, Microservices, Kafka, Spring Boot, Cloud Technologies (AWS, GCP) | Agile , K8s ,DevOps & CI/CD Expert
Spending time on Code Review has the following benefits:
- Ensure code satisfies requirements (does what it has to do compare to ticket description, modeling, etc)
- Ensure code meets standards
- Find bugs before code reaches users
- Share knowledge
- Check that code is clear (understandable), effective, maintainable, secure
- Collaborate on design
- Evolve application code (for every bug or feature, we should fix known tech debt to make the code better)
When Code Review is complete
First and foremost, we rely on the trust of the code author to make updates to the code base as necessary. There are some cases (urgent, hot fixes) when we can obey the rules, but that’s an exception.
The conventional workflow requires the following items before we can mark code review as completed:
- Critical stakeholders (gatekeepers) are agreed
- No tasks and comments left unresolved
- All CI checks pass
Working on Code Review comments
- Don’t take it personally: the review is of the code, not of you
- Kindly ask questions (@mention specific person if needed, don’t make demands)
- Consider separate slack chats and/or 1:1 calls in the case of too many questions, post a follow-up comment summarizing the discussion
- Answer/fix all code review comments (unless they were marked as Minor)
- Don’t hesitate to create separate tickets if code review comments significantly change the scope
- Respond in a timely manner
- Just review your notifications from time to time and let the reviewers know when you provide feedback
- Leave an explicit message when you finished responding to code review comments (that could easily notify the code reviewers to take another look at your PR)
Code Review Anti-patterns
Please avoid the following anti-patterns:
- Nit-picking Skip formatting, whitespace and style issues and leave them to automated tools
- Design change requests If you still need to change what was agreed on at the design (modeling) stage, think about creating a separate ticket.
- 3. Inconsistent feedback Try to be explicit and precise in your comments
- 4. Ghost reviewer Sometimes someone in the review process simply doesn’t respond
- 5. Ping-pong reviews When the code author makes more changes after more comments and suggestions from code reviewers, which repeats forever