Twitter
As per the definition of Wikipedia,
Code review is systematic examination (often as peer review) of computer source code intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.
In this article, Jason Cohen mentions that there exists a formalized system of code review developed by Micheal Fagan at IBM in the mid-1970s. However he points out that the software development process has come a long way since then and we can have process and metrics and measurement and improvement and happy developers all at the same time. The way to achieve this is by using a lightweight code review.
There are four types of lightweight code review techniques:
1) Over-the-shoulder: One developer looks over the author’s shoulder as the latter walks through the code.
This is the code review technique that we use in our organization and that I am familiar with. Once the implementation has reached a level of completion, we initiate such an over-the-shoulder code review process. One of the experienced peers working on the project acts as the reviewer and sits alongside the developer. The developer walksthrough the code implementation explaining why and how the implementation has been done. The reviewer can interrupt the review process to ask any queries and point out discrepancies in the implementation. Small changes can be fixed by the developer during the review process. Larger changes can be taken offline. Once the code review is complete, the developer can check in the changes to the SCM system.
2) Email pass-around: The author (or SCM system) emails code to reviewers.
This is the second-most common form of lightweight code review, and the technique preferred by most open-source projects. Here, whole files or changes are packaged up by the author and sent to reviewers via email. Reviewers examine the files, ask questions and discuss with the author and other developers, and suggest changes.
3) Pair Programming: Two authors develop code together at the same workstation.
Pair-programming is two developers writing code at a single workstation with only one developer typing at a time and continuous free-form discussion and review.
4) Tool-assisted: Authors and reviewers use specialized tools designed for peer code review.
This refers to any process where specialized tools are used in all aspects of the review: collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, and giving product managers and administrators some control over the workflow.
The complete article by Jason Cohen can be found at: Four ways to a Practical Code Review.
Related Posts:
Tags: development
