3 ms·

Further, eliminating bugs caused by any individual code commit is not really the goal behind code reviews in the first place. Finding bugs that the user notices

Further, eliminating bugs caused by any individual code commit is not really the goal behind code reviews in the first place. Finding bugs that the user notices on immediate use is an indictment of the QA process (whether manual or automatic). Code reviews help maintain sanity in the code base, and are useful for sharing knowledge (both in terms of quality of code, and ensuring that there are at least 2 people who have some idea behind the code written). It provides an opportunity to have it read by someone who doesn’t share the same priors as you and helps you identify sections of code that may be confusing for another developer (including future you). If Code review does lead to the identification of bugs that’s just a bonus. There’s a reason Code review does not have a “run the code and test it” component to it and is entirely focused on code, and not whether it runs correctly.

Eleopteryx 8y ago
>Code reviews help maintain sanity in the code base But why delay the shipment of features/fixes to the customer for any of these reasons? If code quality and human understanding is the actual rationale, it could make more sense to review code after it has shipped. In that way, it would cease to be a bottleneck for the developers or customers. Additionally, any bugs that appear in production could be accounted for during the refactoring process. Saying that there is value to a practice is the easy part. We're forgetting to ask when to code review and whether or not code review should ever be a blocker to other processes.
- McP 8y ago
  Because in most environments it's unusual that a developer would go back and change the code after shipping it -they'll have e.g. another high priority bug to fix. Reviewing and refactoring code prior to shipping helps to keep development going sustainably, reducing build up of technical debt.

Eleopteryx 8y ago

>Code reviews help maintain sanity in the code base But why delay the shipment of features/fixes to the customer for any of these reasons? If code quality and human understanding is the actual rationale, it could make more sense to review code after it has shipped. In that way, it would cease to be a bottleneck for the developers or customers. Additionally, any bugs that appear in production could be accounted for during the refactoring process. Saying that there is value to a practice is the easy part. We're forgetting to ask when to code review and whether or not code review should ever be a blocker to other processes.

McP 8y ago
Because in most environments it's unusual that a developer would go back and change the code after shipping it -they'll have e.g. another high priority bug to fix. Reviewing and refactoring code prior to shipping helps to keep development going sustainably, reducing build up of technical debt.