6 ms·
The article actually touches on other methods of review later on. I agree with a lot of points the author makes: there are other methods of increasing velocity
by emptysongglass 3y ago
The article actually touches on other methods of review later on.
I agree with a lot of points the author makes: there are other methods of increasing velocity and reviewing code that don't involve costly PRs. But they've become doctrine at many companies, even tiny startups that don't need a lot of process breaking velocity. Know the right time and context.
- makeitdouble 3y agoHis alternatives to PRs are pair programming and after the fact reviews (when the code is already in the mainline). I don't see any orgs where we would have wanted that, small or big team. I think the main disconnect is that, decreasing velocity is the point of a PR in a way. We usually want to stop the dev process to have people look back at what's developped as a unit of code, and judge it with some distance, possibility from another team to create even more distance from the code. That's where some teams put the checklists, or force a recheck of the requirements to validate the code actually matches what we want, etc. So sure, if someone only cares about velocity PRs are just a burden, but that's far from a consensus IMHO (I'll show my hand by confessing I open PRs for myself, on my own private project, just to review the code in another context than my editor...)