4 ms·
They specifically address areas where the default to pre-commit review, for the reason you just called out: We switch to pre-commit reviews instead of the usua
by relaunched 11y ago
They specifically address areas where the default to pre-commit review, for the reason you just called out:
We switch to pre-commit reviews instead of the usual post-commit review flow if the potential errors/mistakes are costly and can cause significant problems. Some examples of such cases are:
Touching code which deals with privacy and anonymity of users.
Touching a core abstraction since a lot of other code might depend on it.
Touching some parts of the infrastructure where mistakes can cause a downtime.
- mdlowman 11y agoYou're right, but where I work almost anything can cause a bug that affects users. Pre-review eliminates some of those bugs. I would not move to this workflow, although it's interesting to hear from somewhere that it works.
- chipgap98 11y agoWhile the examples given do highlight areas where a bug could do critical damage to a company, there are plenty of ways to break things that cause problems for users. If you put code through at least a lightweight review process you can filter out many of these bugs. While post commit review might work for smaller changes I would rather err on the side of caution and use precommit review. We deploy about the same number of times/day/engineer at my company, so I don't think that the review process is what drives that metric.
- groby_b 11y agoThat makes the assumption you can correctly all identify all those places. And maybe I'm too chicken, and you actually can - but I'd personally still prefer pre-commit. I'm a belt-and-suspenders gal :) But I'm really curious - if you can talk about it, that is - why devs push on average almost 4 changes per day & dev, but a review takes 2 days roundtrip.