Why Design Review Should Precede Code Review and How to Conduct Effective Code Reviews

Code Review (CR) is a practice aimed at improving code quality, catching bugs early, and enforcing team coding standards such as naming conventions, indentation, and spacing.

Large‑scale concerns like architecture or design patterns should not be debated during a CR; they belong to a Design Review (DR). If such issues arise in a CR, it indicates that the DR was insufficient or missing.

At Microsoft, virtually all code must go through a CR. Specific rules differ by department—for example, some require that a component’s designated owner approve the change, while others mandate that at least one senior engineer participates in the review.

Modern tools make CR much easier. Gerrit offers shortcuts and a conversational experience, and Microsoft’s garage project produced CodeFlow, a chat‑style CR tool that lets reviewers select code snippets, add comments, and set the comment status to "fixed" or "won't fix". These features are now integrated into Visual Studio.

In the past, CRs were done by sending patches via email as diffs, with reviewers manually noting line numbers and issues on paper before discussing them over email.

CodeFlow’s interface presents a chat‑like workflow: reviewers comment on specific code sections, authors respond by fixing the issue or marking it as resolved, and the review can be reopened with a new CR if needed. Reviewers can set the CR status (e.g., "in progress", "awaiting author feedback", "signed off").

CRs can also become public debates. In Microsoft, any team member can be an optional reviewer, leading to lively discussions that sometimes resemble public arguments on platforms like Zhihu.

The core goals of a CR are to ensure code readability and consistency, facilitate design discussions, and promote knowledge sharing. All code changes, even those by the code owner, must pass a CR before being merged into the main branch. Automated presubmit checks enforce style guidelines and can block a CR from being submitted, allowing humans to focus on more complex issues.

Google’s internal data provides insight into CR practices: the median number of CLs (change lists) submitted per engineer per week is 3, with 80% of engineers submitting no more than 7; the median number of CLs reviewed per week is 4, with 80% reviewing no more than 10. The median time to complete a CR is 4 hours, 35% of changes affect only one file, 95% affect ten files or fewer, the median change size is 24 lines, and over 75% of changes have a single reviewer.