|
Don't get me wrong - I like them in general. It's just that I spent one day implementing a feature and now three days and counting on the code review. At this point we aren't even discussing my changes, but the design of our unit-test system
Let me check in already!
|
|
|
|
|
Nemanja Trifunovic wrote: Let me check in already!
Not until we have world peace . . .
What me worry?
|
|
|
|
|
How's that saying go? "Meetings, because none of us is as dumb as all of us."
I always felt code reviews went pretty much straight to that.
|
|
|
|
|
Statistically, code reviews - even informal ones - have one of the highest chance of catching bugs. Plus, they happen quite early in the process, further reducign the cost of those bugs.
So yeah, maybe you, like, are, you know, doing it wrong.
|
|
|
|
|
peterchen wrote: So yeah, maybe you, like, are, you know, doing it wrong.
That's a definite possibility. I've only worked at one place that tried code reviews. Those sessions always broke down into hour long discussions about how the white spacing didn't *look* right or a variable should have been named differently. Any bugs saved in those sessions were entirely imaginary. Your mileage may vary.
|
|
|
|
|
thrakazog wrote: Those sessions always broke down into hour long discussions about how the white
spacing didn't *look* right or a variable should have been named differently.
Any bugs saved in those sessions were entirely imaginary
Which represents a process failure at that location.
Process failures can impact software development and even other types of processes at a company in many negative ways.
That however is due to a failure in the way that the process is implemented and not a condemnation of what the process is attempting to achieve.
The best way to produce effective processes is to make sure that managers and employees are specifically and directly responsible for the success of the process while providing avenues to change the process (but not eliminate it nor trivialize it.) If your bonus and your managers bonus is directly based on the success of your processes then both of you are going to be more invested in making it work.
|
|
|
|
|
That's why there are coding standards.
Stop edit wars of taste, and close a trivial discussion once and for all, see also bikeshedding[^].
A coding standard is the first thing to get before doing formal code reviews (When asking about what to prepare for a code review, I was surprised how highly this ranked. Now I know.) It doesn't even need to force one single specific style, it can allow different bracings, etc. A professional developers can stick to a coding style, even if it's not his favorite. If they can't, you need to agree on - or decree - an automatted formatting macro that is used for dispute resolution.
Code Reviews are hard socially. We have better experience with informal ones ("Can we look together at...") - but they don't happen as often as I wanted to. I've read of others praising the advantages of formal ones.
|
|
|
|
|
peterchen wrote: Stop edit wars of taste, and close a trivial discussion once and for all, see also bikeshedding[^].
And now I have the bike shedding book on my kindle. I worry about how easy amazon makes this stuff sometimes
|
|
|
|
|
I didn't regret the majority of my impulse purchases.
But that might just be Stockholm Syndrome.
|
|
|
|
|
+5
/ravi
|
|
|
|
|
very code review I'v been in has been a complete waste of valuable development time. It usually turned into "Why did you do it this way???? My way is better...".
Total waste
If it's not broken, fix it until it is
|
|
|
|
|
Kevin Marois wrote: Why did you do it this way???? My way is better
Code reviews can be a way of educating developers and also a way to insure that tribal knowledge increases.
And that is often a good thing.
|
|
|
|
|
jschell wrote: Code reviews can be a way of educating developers and also a way to insure that tribal knowledge increases.
And that is often a good thing. Ah, to work in such a wonderful environment.
Instead, the places I've worked, the managers expected that ALL bugs would be located and failure to do so would rain hell upon those involved in the review.
"When the going gets tough, the tough take meetings" seemed to be their operating motto.
I once had to endure three days of meetings which called into to question my knowledge of the product, my knowledge of the language, my knowledge of programming principles, and my genealogy, because I had faithfully rewritten a module as a workalike that exposed a bug (not in my code) that went from non-reproducible to an absolute certainty.
While I was having my tongue nailed to the tabletop, one of my colleagues found the bug and the bug reports of it.
Calling it a failure of management would be an understatement. I have yet to discover how one can make a change to management, short of leaving the company.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
BrainiacV wrote: Instead, the places I've worked, the managers expected that ALL bugs would be
located and failure to do so would rain hell upon those involved in the review.
Ok, but that has nothing to do with this discussion.
What you have is an example of management failure. Nothing else.
|
|
|
|
|
There's a name for craftsmen that blame their tools, it's on the tip of my tongue.
Code reviews are socially hard (which for some developers ranks slightly above NP-hard). As much as I despise "This is John Consultant, he will be with us for two days and tell you how to do your job", this is one situation where an external authority to drill individuals isn't the worst solution.
It is problematic to get the right people behind it, and if it doesn't work by its own, you have to impose ridculously rigid rules.
Not that you have to do code reviews, and there are likely shops who would never get it done. just don't throw out the coconut because the peel is so hard.
|
|
|
|
|
Yap. before it smells better to sanitize as early as possible.
Wonde Tadesse
|
|
|
|
|
peterchen wrote: Statistically, code reviews - even informal ones - have one of the highest
chance of catching bugs.
I'm interested to see your sources on this statement. All the research that I've done on code reviews says that code reviews are not very effective at finding bugs.
|
|
|
|
|
Steve McConnell, "Code Complete", cites a comparison of verious "bug slaying" methods.
The main message is: no single one is sufficient.
The second is: formal code reviews rank highest or second-highest. (McConnell informally concludes in conjunction with other arguments that anything that makes someone read the code is pretty damn efficient.)
At home I can look up the original paper (though havign that book is kinda recommended anyway )
|
|
|
|
|
I worked with a spiteful piece of shyte at one job who got a competent contractor (who he didn't like but the rest of us did) dismissed because of his code review. C'mon, it was VB6 so what did he expect it to look like? The developer who did the review was a tosser. Maybe he was pee'ed off because four of us set up the companies first C# group and he wasn't in it.
Done correctly, code reviews can be useful but not when it's used vindictively as that arsewipe did.
"I do not have to forgive my enemies, I have had them all shot." — Ramón Maria Narváez (1800-68).
"I don't need to shoot my enemies, I don't have any." - Me (2012).
|
|
|
|
|
PHS241 wrote: Done correctly, code reviews can be useful but not when it's used vindictively as that arsewipe did.
If it moves, compile it
|
|
|
|
|
PHS241 wrote: ne correctly, code reviews can be useful but not when it's used vindictively as
that arsewipe did.
However that is a management failure, not a process failure.
|
|
|
|
|
You should rather discuss the design of your code review process.
It should not be used to talk about things that the reviewer wants to get of hisher chest. I'm sure someone at your place is aware of that.
|
|
|
|
|
Code reviews before checking in seems like overkill to me. I like 'spot check' reviews where you look at each other's code now and then and make sure the style is okay. A continuous integration server and test discipline should ensure that you know your code is functionally correct, and style is vastly secondary to that and not worth holding up development as a matter of course for.
|
|
|
|
|
BobJanova wrote: and test discipline should ensure that you know your code is functionally
correct
And how do you know that your test discipline is correct if you do not review the tests?
|
|
|
|
|
You need to review test procedure, coverage and so on at some point. But the point I'm making is that it doesn't need to be reviewed before you check something in, and you don't need to review every single commit ... just a sample of what people are doing to check that they have the right habits.
|
|
|
|