3 replies to this topic

[PsychoCoder]

Do you utilize code reviews in your development process? Do they improve the quality of code that makes it into a production environment?

Before I get into my spiel I would have to say, according to experience, that the answer to both of these questions is a resounding yes. The last Fortune 500 company I worked for it was me who as responsible for writing the departments code review standards (and the coding standards document but that's for a different discussion).

This took me several weeks of reviewing other formats used by various companies and what was currently happening at said company (that was the research part), then a couple more weeks of actual writing and revising. Once it was done, then came the hard part of implementing the process. Change is a hard thing to get some seasoned developers to accept, and I knew the ones who would fight it tooth & nail.

I did a meeting with the entire development team/department and explained how it's been proven time and time again that code reviews do indeed lead to less defects in your software. Core reviews are viewed by a lot of developers, and probably for good reason (I've seen some bad policies before as well) as a painful experience to have to endure, to survive. Everyone knows what the purpose of a code review is, so when I wrote up the guidelines I focused more on what a code review is not:

• A code review is not a way to try and show the reviewee that you are superior to them and that their skills are dwarfed by yours. This will do nothing but create instant animosity and you will accomplish nothing.
  
• A code review is not your chance to take a shot at the reviewee. It's not the developer that is being reviewed it's the code that was written.
  
• A code review is not a chance to belittle another developer because they don't write code the same way you do

An effective code review can actually be a non-painful (some would say informative, relaxing) experience if done properly. I'm currently looking for my copy I saved when I left the company and will post it as soon as I find it. Within 4 months of implementing my code review guidelines we seen a 55% decrease in bugs & flaws that made it as far as QA, and a 65% drop in ones that made it into production.

I've worked for companies before that had no kind of standardized code review standards/guidelines in place and let me say it would never happen again. I'd say that at least 90%+ of all bugs made it as far as QA and I bet 80%+ of those made it into production, and it always went downhill from there.

So let's get y'alls take on an effective code review, do you think it helps improve the quality of code that makes it to QA and then into production. I know I've seen both sides of the coin and the differences were staggering in experience.

[BlaineSch]

Maybe you should setup a review program so it's anonymous. Like 5 users would submit code, then each user would review the code of an anonymous users work, resubmit it will suggestions/fixes and the new person would see the results and know how to improve.

It would help people without the threat of all 3 of those rules.

[WingedPanther]

It depends on how the code review process is done. If it's dynamic, interactive, and with a goal of improvement, it can be a great thing. If it's actually a rubber-stamp, then it's a waste of documentation. I've seen both.

[PsychoCoder]

Our code reviews were one on one (I say were because I no longer work there), and once they were implemented we say a huge decrease in bugs that made it to QA, so in my opinion they're a good tool when it comes to keeping bugs out of your software.