On Sat, Dec 06, 2014 at 04:43:56PM +0000, Paulo Pinto via Digitalmars-d wrote: > On Saturday, 6 December 2014 at 15:14:23 UTC, H. S. Teoh via Digitalmars-d > wrote: > >On Sat, Dec 06, 2014 at 08:46:58AM +0000, Paulo Pinto via Digitalmars-d > >wrote: > >>On Saturday, 6 December 2014 at 08:26:23 UTC, Brad Roberts via > >>Digitalmars-d > >>wrote: [...] > >>>I've worked at several companies, both large and gigantic, and it's > >>>worked very well at all of them. Code reviews are an important > >>>part of healthy and quality code development processes. > >> > >>Maybe I have worked at wrong companies then. > >> > >>In 20 years of career I can count with one hand those that did it, > >>and most developers hated it. Never lasted more than a few meetings. > >[...] > > > >Huh, what...?? Meetings? For code review??? How does that even > >work...? > > > > Easy, the meetings get scheduled with each developer getting a module > for review. > > Those developers then print the code and get some days for review > until the meeting. > > The meeting takes place and afterwards each developer updates its own > module with the gathered feedback.
Whoa. People actually do that??! If that's how code reviews are carried out, I can totally see why it wouldn't work. While I'm OK with spending 15-20 minutes reviewing a prospective code diff to be merged into mainline, reviewing an entire module would take up way too much time, and would be too quickly invalidated (as more changes pile up) to be of any long-lasting value. Some of the code I work on contains files with 4000+ lines of code (sometimes up to 8000+ lines); printing that would fill a small book, and would take at least a week (if not more!) to thoroughly review. By then, the review would be worthless 'cos the 50 other developers have been making changes for a *week*. That's 40 hours * 7 days * 50 developers = 14000 man-hours worth of work. While not all of the work would touch a single file, enough of it would touch code related to that file, that will make any static code review essentially worthless by the time it's done. Such an approach cannot possibly work in today's scale of software projects. > The scenario you described I have only seen live in startups. > > I never saw a corporate institution care about code review, specially > if the projects have offshored teams, as the ratio is usually 10:1. If "code review" means the process you describe above, yeah, I can totally see why!! My employer can't be accurately described as a startup anymore, as it has grown to thousands of employees worldwide over the past 10+ years of its existence. But despite all the other flaws I often bemoan, code review is something ingrained in company culture. If code that passes through the review protocol I described still ends up being of such inferior quality as I witness every day, then I truly dread seeing what it turns into when there is no review process at all!! (Or not... I guess it would just be IOCCC all over again on a larger scale. :-P After all, I *did* write a monstrosity that won an ignoble award from the IOCCC once... so I just have to get used to doing that on a regular basis. :-P) In any case, the only code review process that I can see having any chance of being practicable is review per change request. Reviewing by module is simply not feasible in today's kind of software development, esp. where large teams are involved. T -- We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true. -- Robert Wilensk
