The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
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
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.
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.
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.
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.
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.
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).
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.