In this week’s blog we’ll talk about peer review, sometimes known as a code review or walkthrough.
What is it?
This is a thorough technical and logical line-by-line review of code. It is usually done in a small module, like a program, subroutine, object, method, etc. Sometimes a meeting can be held to discuss any issues related to the revision.
Why?
One of the main objectives of this process is to identify possible improvements and ensure that business requirements are met.
Advantages, disadvantages
A lot of programmers complain about code reviews because they think it takes a lot of time. This may be true in some cases. Nevertheless, the drawbacks are usually outweighed by the benefits. The main advantages of this process are the following. First of all, it helps reduce bugs. In the long run, all that work will be significantly less if you find those bugs later on when the project is much advanced. That means less rework. There’s also more team communication. All of this helps to improve the team cohesiveness.
How does it work?
The methodology varies from company to company but most methodologys follow this 3 step process consisting of preparation, review, and follow-up. Here’s a look at each step.
Preparation
First, the code being reviewed must be complete, tested by the programmer, and in the programmer’s view, ready for the next step in the development life cycle. The code and other affected project components, such as documentation, test cases, a project schedule, or requirements changes must also be available to the review participants
Review
Reviews are conducted as needed, usually based on the rate of code output. The frequency of individual participation in a peer review depends primarily on the size of the programming team. A team of three programmers might include all three in every review. Larger teams might be able to rotate participation based on experience, skill level, subject matter familiarity, or site-unique factors.
Follow-up
Follow-up provides evidence of the meeting’s success and incentive for the continued use of reviews. The value of future reviews will be degraded if decisions are not enacted, and eventually programmers will view the process as just another waste of time. Follow-up is critical for all participants, especially the programmer. The documentation must be kept in a central location where anyone can reference it.
References
Developer’s guide to peer reviews
https://smartbear.com/learn/code-review/guide-to-code-review-process/
Cellar Door Blog 