4 ms·
> If someone is implementing something that is inherently complicated, I much prefer to see the complete picture and do one thorough review than be drip-fed lit
by kqr 5y ago
> If someone is implementing something that is inherently complicated, I much prefer to see the complete picture and do one thorough review than be drip-fed little pieces for a series of smaller reviews. That way, I can take the time to understand what is really happening, and look for potential dangers
But isn't this what design review is for? So you don't end up in a position where you suddenly have a 500 line change set based on misunderstood requirements, and you have to review the code to find out?
Many of the things you mention should be caught in design review, and then even more of them would be caught in an early draft review (say 50–150 lines of code) with most of the actual implementation stubbed out.
That way, when you finally get to the big 500 line full implementation, almost all of the high-level concerns have been worked out at an earlier (cheaper!) stage so only minor comments remain, and those it is effective to be drip-fed.
- Chris_Newton 5y agoIdeally, yes, those kinds of things would probably happen and they’d reduce the load on any final code review. In practice, I find a lot of development groups do code reviews prior to accepting changes into whatever deployment pipeline they use but aren’t so comprehensive or consistent with reviews at earlier stages. Even with useful reviews at the design stage, I would still always look out for those kinds of issues as part of a code review, though. The approach might have evolved during implementation, or that implementation might have unintentionally deviated from the intended design. Also, sometimes the code is doing something inherently complicated and there just isn’t much to see until a whole algorithm is substantially implemented.