3 ms·
To me, there are two main reasons to review code (before merge): quality and trust. Quality should come way before trust, because if you don't at-least-mostly t
by dwb 3y ago
To me, there are two main reasons to review code (before merge): quality and trust. Quality should come way before trust, because if you don't at-least-mostly trust contributors then there's something wrong that code review won't fix. And if you think anyone is likely to go back and review already-merged code for quality when your manager is pushing for "velocity" (especially as it probably works, to some extent), well, you're probably wrong.
If you think you can deal with the quality hit then yeah I guess just go crazy, spurt out another buggy pile, just don't bother me about it.
- swiftcoder 3y agoYou are on the money, but I think quality is much more subject to automation than trust is. On a previous team, implementing team-wide autoformat-on-save and a decent linter eliminated ~75% of code review feedback overnight. If your code reviews are mostly enforcing cosmetic properties of the codebase, automate that shit. You have similar levers to pull in other areas. Fail the PR if the test coverage drops, add warnings on branch complexity...
- dwb 3y agoI mostly agree, and this maybe gets a bit philosophical, but for me true quality needs a human too.