6 ms·

> Code review, or “Approval”, should not be a requirement for a Pull Request to be merged. Shouldn‘t it? With all the code I‘ve seen, I think this works only i

> Code review, or “Approval”, should not be a requirement for a Pull Request to be merged. Shouldn‘t it? With all the code I‘ve seen, I think this works only in very specific projects. In all the other projects, this process will lead to many bugs in production that could have been caught by a short code review by a single person. > People get to merge their own Pull Requests. This way they’re in control of whether their change is a “Show” or an “Ask”, and they can decide when it goes live. Don‘t like that. It‘s a „I can decide and I can do whatever I think is best“, which will obviously not always work.

jka 5y ago
Broadly agreed. It's taken me a while to adjust to various different code review practices, styles, and environments, but in the end the opinion I've settled on is that no matter how frustrating it might seem to be to wait for review (especially if it takes a long time), it's always better to have at least one person review any change, even seemingly minor ones (with the possible, albeit not-always-simple, exception of reverts/rollbacks). Why? - It reduces the chance that you get into thoughtless fix-merge-fix-merge loops (it can still happen, but knowing that changes may take time for review has an incentive-correction effect) - It shares knowledge about code changes with other people, so that if-and-when (usually when) bugs occur in that part of the codebase in future, you're not the only person somewhat familiar with them - It provides training and learning opportunities for reviewer and reviewee alike; discussions, scenarios and opinions can all be shared and worked through, and can shift behaviours and improve system and process reliability If there's some magical workflow that can allow shipping your own changes without losing any of those benefits, that will be impressive; for now I'm curious to learn more about this approach, although initially skeptical.

jka 5y ago

Broadly agreed. It's taken me a while to adjust to various different code review practices, styles, and environments, but in the end the opinion I've settled on is that no matter how frustrating it might seem to be to wait for review (especially if it takes a long time), it's always better to have at least one person review any change, even seemingly minor ones (with the possible, albeit not-always-simple, exception of reverts/rollbacks). Why? - It reduces the chance that you get into thoughtless fix-merge-fix-merge loops (it can still happen, but knowing that changes may take time for review has an incentive-correction effect) - It shares knowledge about code changes with other people, so that if-and-when (usually when) bugs occur in that part of the codebase in future, you're not the only person somewhat familiar with them - It provides training and learning opportunities for reviewer and reviewee alike; discussions, scenarios and opinions can all be shared and worked through, and can shift behaviours and improve system and process reliability If there's some magical workflow that can allow shipping your own changes without losing any of those benefits, that will be impressive; for now I'm curious to learn more about this approach, although initially skeptical.