• Let computers do the boring parts: automatically verify that the code builds, tests pass, code matches team style and has no unused imports or unused variables.

  • Settle style arguments with a style guide.

  • Start reviewing immediately, ideally within minutes. Treat code reviews as a high priority. The absolute maximum turnaround on a review round should be one business day.

  • Start high level and work your way down. Keep the number of notes below 20.

  • Be generous with code examples. Lighten the author’s load by writing out some of the changes you’re suggesting.

  • Never say “you”. Drop or replace with “we”.

  • Frame feedback as requests, not commands.

  • Tie notes to principles, not opinions. See SOLID.

  • Aim to bring the code up a letter grade or two. Not F -> A, but E -> C.

  • Limit feedback on repeated patterns.

  • Respect the scope of the review. If the changelist doesn’t touch the line, it’s most likely out of scope.

  • Look for opportunities to split up large reviews. No reviews greater than 400 lines of code. Suggest ways to split.

  • Offer sincere praise. Give positive feedback as well.

  • Grant approval when remaining fixes are trivial.

  • Handle stalemates proactively: talk it out, consider a design review, concede or escalate.

Checkout the full publication by Michael Lynch: part1, part2.

comments powered by Disqus