Very few people doubt the usefulness of peer code reviews to improve software quality. Intuitively I would put it as one of the factors with the highest impact on quality, right up there with good design and thorough testing/validation.
Most projects I have worked on, did at least lip-service to code-reviews, but most failed to actually do it systematically. Not surprisingly since code-reviews done well are very time-consuming and put a huge burden on someone else other than the author of the code. The key to success would seem to minimize the hassle and burden put on the reviewer.
Some common ways to do that might be
While most word-processors support reviews through incremental change tracking and embedding editorial contents into documents, there is no such support in most commonly used software development tools.
I think that the popularity of open-source projects has done a great deal in promoting and popularizing collaborative software development tools. It would be much harder today to find a software developer who has never heard of version control or issue tracking system and wouldn't think it quite normal to use them.
The good news is that collaborative code-review tools might be next. While 10 years ago, it would have been hard to find any references to code-review tools, a casual web-search now shows a few open-source and commercial options:
Maybe a few years from now, a code-review system will be considered as natural and integral part of any project's development environment as we would consider today email, version control, issue-tracking or wiki/document sharing systems.
Most projects I have worked on, did at least lip-service to code-reviews, but most failed to actually do it systematically. Not surprisingly since code-reviews done well are very time-consuming and put a huge burden on someone else other than the author of the code. The key to success would seem to minimize the hassle and burden put on the reviewer.
Some common ways to do that might be
- Pair programming: the burden of review and credit for delivering the code are shared equally. While pair programming certainly seems to have many advantages and some very enthusiastic followers, it may be hard to implement in some places. While two pair of eyes certainly see more than one, it might also be helpful to get fresh pair of eyes do the review, who was not part of the design process.
- Walk-through: the programmer presents the changes to the reviewer and walks him/her through the code, explaining his/her choices and answering questions. The risk here is that since the author is in driver seat, that the reviewer might be too easily coerced into accepting the author's point of view. Capturing the reviewer feedback and making sure it is properly incorporated is also particularly hard in informal approach. The need for shared face to face time for the review also puts constraints on author and reviewer and does not work very well for distributed teams or making use of unproductive time - e.g. on the train ride home.
- Tool support: using a code-review support tool, the reviewer can at their own leisure look at the proposed changes and can add any comments and suggestions as annotations to the code changes presented by the tool. Author and reviewer can go back and forth with new versions and responding to each others comments until all the issues have been resolved. Such offline reviews, where author and reviewer never meet can be very efficient for both of them, but drawn out in time, as each takes their time to respond on each revision.
- I find myself less tempted to cut corners (yes, I am naturally lazy!), if I know that my code will be reviewed line by line, causing me great embarrassment in front of my team-mates and peers.
- If find that by having to spend significant amount of time carefully reviewing other people's code is a great learning experience. Looking closely at other developers code can often open up my eyes to new ways of doing something. For anybody who has mastered the craft of programming beyond what can be learned from books, looking at other people's code is one of the best ways to grow further as a programmer.
While most word-processors support reviews through incremental change tracking and embedding editorial contents into documents, there is no such support in most commonly used software development tools.
I think that the popularity of open-source projects has done a great deal in promoting and popularizing collaborative software development tools. It would be much harder today to find a software developer who has never heard of version control or issue tracking system and wouldn't think it quite normal to use them.
The good news is that collaborative code-review tools might be next. While 10 years ago, it would have been hard to find any references to code-review tools, a casual web-search now shows a few open-source and commercial options:
- Rietveld open-source, inspired by the Mondrian tool, which I use daily
- Review Board - open-source
- Codestriker - open-source
- PeerReview plugin for Trac - open-source
- CodeCollaborator - commercial
- Crucible - commercial
Maybe a few years from now, a code-review system will be considered as natural and integral part of any project's development environment as we would consider today email, version control, issue-tracking or wiki/document sharing systems.