Is the Code Review Parallel Programming or Singleton?

[Matthew Dennis]

913 x 613 = 4213 Which just show why everything seems to go wrong. The universe is based on an unlucky number.

[Mike Hankey]

Good point!

"Life can only be understood backwards, but it must be lived forward." Kierkegaard, Søren

[Mark_Wallace]

Don'tcha just hate it when you invent a perfectly logical term, only to discover that some dweeb has been using it for something else?

I wanna be a eunuchs developer! Pass me a bread knife!

[tom1443]

My opinion is that anyone can participate as a moderator, reader, or recorder. But if you want a meaningful review you need 1.) people familiar with the domain and 2.) people with the time to actually look at the material before the review starts. Otherwise just run it through some static analysis tool and don't bother with the review - it will just be a coding standards review anyway.

[Carl_Sharman]

The biggest challenge I've found with code reviews is people actually doing them long term. They'll run for a while, everybody will congratulate themselves on how useful they are, then at some people will stop doing it. And when people stop doing it, it's always for the same reason "We don't have time". This is partially true, but also hides the biggest reason, IMO: "We can't be bothered". Anybody that's ever done code reviews knows how much value they have, but the trouble is they can be time-consuming, tiresome, hardwork and boring. With that in mind, I'd recommend the following: 1. Don't have dedicated reviewers, because they will get bored quicker. Let everybody get involved; share the pain around. 2. Keep the reviews short and sweet. Split large reviews into multiple sessions. 3. Don't review in more detail than you really need. 4. Make sure everybody understand the benefits and are sold on the idea before you start. 5. Don't worry too much if you have a really busy period and fall behind on the reviews. Just let them go; draw a line in the sand and start again. Having said that, if you do have a senior dev that just loves doing code reviews and is happy to do them all, you might well be able to ignore all of the above. Just seems unlikely! Happy reviewing, Carl

[Dave_6]

Start with a software tool for automated review. They can check for lines of code per procedure (e.g. 30 max), complexity (e.g. simple, moderate or high), a sufficient number of comments, parameter validation and error handling. Each team member can use it to review their own code before passing it to another team member for review. Don't track bugs found in self-review. After a developer says they are done with some code and have checked it in, another developer should review it for compliance with pre-defined standards. Bugs found in these reviews should be tracked in your bug tracking system. You should have more senior developers reviewing less experienced developer’s code and a senior developer review other senior developer’s code. Inexperienced developers (new hires out of college) or poor developers don't do code reviews. They should review bug tracking logs for code reviews to help understand code reviews and standards. After the code review passes, the code goes to test. QA could be a developer on your team. Always track bugs found here in your bug tracking system. The test process doesn't look at code. They just validate functionality. This process can also be automated with software tools. In a software project, all of these activities are going on throughout the process.

[Alan Balkany]

Transparent aluminum!

[Toto1107]

We currently are trying to revive / implement Code Reviews. I’ve included a few links we’ve used as references. We had tried in the past to do formal reviews, in the beginning there was support but as schedules became tighter…it got left by the curb. We are now trying with informal reviews, and collecting metrics to support adding time to the project schedules for inspections. Realistically, there is not enough time to review everything. So guidelines help to consider potential risks like: The software … • Involves multiple 3rd Party development partners. • Involves new technologies or technologies unfamiliar to the development team. • Introduces a new or significantly revised software architecture. • Involves a complex architecture with many software assemblies and/or parts. • Includes parallel development of software assemblies and/or parts that share an interface (e.g. mutual communication channel). • Supports or will be reused by more than one software part, software assembly or software project. • Supports a safety critical software part, software assembly or software product. • Supports a feature or function that is critical to system operation (e.g. could result in a shutdown) • Supports a feature or function that is critical to the customer. • Is new or has been significantly revised (more than x %). • Will be developed by a contractor or 3rd party. • Will be developed by an inexperienced software developer. • Will be developed by a software developer who is new to the program. • Relies on multiple interactions between subsystems • Contains time critical features or functions We also use static code analysis to catch *simpler* common mistakes, code reviews focus on logic / requirements / functionality errors. http://www.ganssle.com/articles/inspectionspart1.htm http://www.processimpact.com/pr\_goodies.shtml http://www.crosstalkonline.org/search-all-issues/

Toto1107

[jschell]

First define the goals of the review. Some or all of the following are possible. - Code bugs - Code quality (is it maintainable.) - Correct implementation (meets business requirements) - Security - Knowledge sharing. This can include product, business and/or technical. Once goals are defined then identify which participants for a review who would be necessary to meet the goals. For example interns are not necessarily participants unless the last item is in place. That said, one cannot review ones own code. Regardless of expertise another pair of eyes even without the necessary experience is going to provide some benefit. In my experience it also helps to emphasize that reviews are to be de-personalized. Enforcing this is a management role. For example if one person doesn't like where brackets are placed then, excluding code dev guidelines that specify it, then the manager must tell that individual that that personal preference is not be be brought up again. And participants must be encouraged, strongly, that issues in the code must be discovered. If someone is reviewing hundreds or thousands of lines of code and can't find a single thing wrong with it then they probably are not actually reviewing the code. Again this is something management must enforce, ideally, by using number of issues found in reviews (not created) as part of the employee review process.

[Member 4409457]

I think code review should be the responsibility of whole team. The more you share the code with other the more and more idea will came out. And the review may look into the code in some interesting viewpoint. Also the reviewer could just learn a new way to do something. So, this is a win-win situation both for the coder & reviewer as well as for the team. Because the code will be less prone to error once it has been reviewed by others.