3 ms·
I have slowly managed to train my colleagues that a PR should be "one thing". My team ends up doing a whole lot of internal tooling, so we're frequently creatin
by randomswede 6y ago
I have slowly managed to train my colleagues that a PR should be "one thing". My team ends up doing a whole lot of internal tooling, so we're frequently creating "new small tool" and one colleague started by working away and only raising the PR when the toll was essentially done.
This, essentially, ends up with a PR review that takes hours to complete, only to end up with at least a few "changes required". Leading to updates, and a re-review, usually with enough time lapsed that the review ends up being "from scratch" (partially due to the size of the PR, partially due to the time lapsed).
We've now mostly converged to "start with a PR just setting the skeleton up and one testable function", meaning that what used to be a single monster PR now ends up as 5-15 PRs, each one much easier to review. Amusingly, this also tends to end up with things being completed faster.