|
|
|
|
|
by mvgoogler
4614 days ago
|
|
> partially for inspecting the product, and partially for teaching and inculcating cultural norms Yes! I would go further and say that - without discounting their value for catching bugs - the _largest_ benefits of doing code reviews are cultural rather than technical. |
|
With large teams, especially if distributed or partially outsourced, code reviews can ensure code quality. But also be a total bottle neck if over-bureaucratic and some reviews are of low quality due to lack of context. Often combined with ivory tower architects as well.
In smaller, agile and especially collocated teams code reviews will flag issue unnecessarily late in the process. Just pair from the start instead to ensure no short cuts or dodgy code slips through, and automatically spread the knowledge. If you do not trust two of your developers combined then you do have a serious problem.
You can though in addition have small and short swarming/tripling/quadrupling sessions in front of 1 computer to look at especially important issues.
If you do neither code reviews nor pairing then you are in trouble.