News for hackers. Stuff that matters.

A comment on Moving Fast with High Code Quality. Parent comment

Re:Moving Fast with High Code Quality by relaunched on Monday July 27, 2015 @05:29PM (#9958141)
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.
[ Parent | on HN ]
Re:Moving Fast with High Code Quality by groby_b on Monday July 27, 2015 @08:45PM (#9958919)
That 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.

[ Parent | on HN ]
Re:Moving Fast with High Code Quality by mdlowman on Monday July 27, 2015 @05:42PM (#9958212)
You'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.

[ Parent | on HN ]
Re:Moving Fast with High Code Quality by chipgap98 on Monday July 27, 2015 @06:04PM (#9958328)
While 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.

[ Parent | on HN ]