Rethinking Code Reviews

Based on talk “Code Reviews: Building Better Code and Stronger Teams” @ MeetingC++


What is a code review to you?


What is purpose of code reviews?

  • Quality assurance

    • “The final human check after all automation”

    • Enforce standards, patterns, naming

    • Offers fresh perspective (author bias)


What is purpose of code reviews?

  • Quality assurance

  • Knowledge sharing

    • Educate about language & tools

    • Share context and decisions

    • Leverage diverse insights


What is purpose of code reviews?

  • Quality assurance

  • Knowledge sharing

  • Mentoring

    • Elevate less experienced devs

    • Improve team communication


How to do code reviews?

  • Syncronous: Pair/Mob programming, review meetings

  • Asyncronous: Pull requests


Pair programming

  • Real-time collaboration

  • “Review is a by-product”

  • Best for onboarding and complex problems


Mob programming

  • One types, others guide

  • Shared understanding

  • Best for exploratory work and architecture


Review meetings

  • Pre-scheduled, multiple stakeholders

  • Best for critical code/architecture


Pull requests

  • Written only: risk of misunderstanding

  • Enables flexibility (not real time)

  • Best for day-to-day code changes


Pull Requests: Issues and learnings


[REVIEWER] Common issues of pull request

  • Late feedback

  • Tone in written feedback!

  • Comments lack explanaton or educational value

  • Everything gets commented -> “pair programming”


[REVIEWEE] Common issues of pull request

  • Too big, mixed changes

  • Shared too early (not green)

  • No context/description on entry point

  • No self-review


The AIR Formula for Better Comments

  • A = Action: What should be done

  • I = Information: Why it matters

  • R = Reference: Where to learn more

Example:

  • “🔴[DESIGN] Tight-coupled dependency. Use DI. See docs”


Call to Action

  • Self reviews of PRs!

  • Be kind and empathetic in reviews, (give kudos!)

  • Discuss review culture within your team

  • Start seeing reviews as mentoring opportunities

  • Try incorporating asynchronous reviews

  • Try AIR formula for comments, and, or

  • Try out adding intent to the comments (blocker, nit, question, kudos).

  • Avoid reviews which are just “Looks Good To Me”


Thank you!


Points of discussion

  • How are code reviews done in your team?

  • What challenges have you faced?

  • What practices worked well for you?

  • Have you tried any asynchronous review methods?