Giving better code reviews

Code reviews are presented as a key process for spreading knowledge and best practices across a development team. The text argues that review quality is often inconsistent because teams leave improvement to individual reviewers, and that weak reviewers set the ceiling for the whole team.

Reading notes

#

• The review process has at least two phases, and many people stop at the first one.
• The light pass looks for obvious mistakes, at least one test, deleted commented-out code, and styleguide violations that linters do not catch.
• The contextual pass goes deeper and checks idiomatic framework use, test coverage, meaningful test behavior, stronger tests, refactors, edge cases, logical omissions, and missing spec details.
• Reviewers should question code kindly, assume mistakes may exist, and ask about specific lines when needed.
• Pull requests should be small, because large diffs reduce review quality and force repeated reviews after changes.
• When a reviewer lacks context, the author should look for another reviewer or walk through the diff step by step.
• Blocking and non-blocking comments can help separate essential issues from optional ones.
• Reviewing code is described as a craft that should improve code understanding, review criteria, and the team’s ability to write correct diffs.