4 ms·
"Small Reviews > Large Reviews" This depends on what you are looking for. For style and "obvious" bugs? Agreed. For finding bugs? Couldn't be more wrong. Func
by sheepmullet 11y ago
"Small Reviews > Large Reviews"
This depends on what you are looking for. For style and "obvious" bugs? Agreed.
For finding bugs? Couldn't be more wrong. Functionality based reviews pick up far more defects, if done properly, than reviews of change sets. And it's because you pull back and think about the entire context of the feature.
Of course they also require a much more significant time investment and need to be run differently than a standard code review, but they are also much more valuable.
- sytse 11y agoI agree sometimes you need to review a piece of functionality. But I think of this more of an escalation of a change set review. As in: 'this code stinks, why is that, lets look at the bigger picture, mmmm, lets schedule a review for this'. From the article: "It’s possible that a larger piece of code needs refactoring. If this is the case, do it within the merge request or schedule the refactoring as a separate issue.".
- sheepmullet 11y ago> I agree sometimes you need to review a piece of functionality. But I think of this more of an escalation of a change set review. I find it's more like the difference between unit testing and integration testing. No matter how well you unit test it doesn't replace integration testing. Most of the bugs I run into in prod are not the result of localised issues but are rather caused by the interplay of different modules/classes/subsystems.
- sytse 11y agoI agree there is scale in this. My point is that the smaller ones (here is a bug we need to fix/code with high churn) are the best way to find the larger ones (here is code we need to refactor.