Code Reviews – Importance of Positive Feedback

There are a few things that code reviews can do for you, and some things they can't. The arguments in favor of code reviews:

• Collective ownership
• Find bugs (QC)
• Enforce consistent style (QA)
• Mentoring

Many agile processes tackle those in different ways:

• Collective Ownership: everyone on the team is responsible for the project, which means everyone's eyes will be on the code at any given time.
• Free to refactor: this takes code reviews to the next level, and allows anyone on the team to perform refactoring as necessary.
• Unit tests (QC): unit tests are more efficient and less prone to human error then visual inspection. In fact, I have yet to find a more efficient means.
• Pair programming (QA): takes care of mentoring and provides early refactoring advice as the code is written. This is also still a controversial topic, but I find it helps while ramping up a new developer. It's also a good time to enforce coding standards.

In essence there are other avenues of taking care of the potential gains you would normally have doing peer reviews. My personal experience with peer reviews is that they are very inefficient mechanisms and are not effective at finding bugs or larger design flaws. However, they do have their place in some teams, and on projects where agile is not feasible (for whatever reason), they are quite necessary.

Look at how facebook does it with their own app, called phabricator: http://phabricator.org/

They basically commit on a per issue basis, and for each issue, the code is shown, which is to be reviewed by someone. The code doesn't go into their main repository until the reviewer said it's ok to do so.

I guess it makes it more fun.

Also, perhaps a code should be assigned to two people: one who does it and one who reviews it.

Albeit perhaps your teammates don't believe in this review thingy.

Personally, in lack of reviewers, I used unit tests for lower-level functions and "the janitor test" for all the rest: the janitor test is called that way, because even the janitor should be able to understand your code.

I usually removed some minor parts, like block / function scope brackets, visibility notations, sometimes even types, and showed it to managers, domain experts, mates, whoever requested the code: "is this what you want?"

Also, going there personally and not leaving until reviewing is done helps.

Or, in case you're not fine with the team, or they're not fine with you, you know, "if you can' change the company, change company"...