Introduction

Peer Code Review is a higher code quality review system incorporated in a DotNetNuke Framework to deliver a better quality product by making it more robust against breakages. Unintentionally, service engineers, while checking in code, may lead to certain code breaks elsewhere in a table, some of which include build, packages, automated tests and functionality.

And this is where Peer Code comes into play as it helps upgrades the system to a better code quality.


Concept of a Peer Code Review

Peer Code Review is a cheap option with specific emphasis on the word ‘Peer’, the review engineer in the team, similar to a buddy-pair concept.

The Procedure

While making changes to check-in codes in TFS, an engineer sets a code reviewer field, or aTBD,and notifies the other engineer, a Review Engineer.

The Reviewing Engineer then analyzes this checked-in code and confirms this in the TFS change-set (instead of a TBD), after reviewing the code. In case a problem persists, both engineers work together and resolve the check-in code. These checks-in are also reviewed for consistency and breakages, thereby making it an iterative process.

Teamwork anomaly

While a few service engineers find it convenient to get their codes reviewed by another peer, there are some who are hesitant or apprehensive. It is a matter of procedure to a company who takes up such procedural changes to implement it across their work domain.

One such method adapted was running reports (or custom programs), in TFS, to see which change-sets didn’t have a reviewer. These engineers were then pulled-up and asked to complete the pending review. Done a handful of times, this helps the system adapt seamlessly.

System Efficiency

Of the many anomalies in systems, being overworked by resorting to unnecessary or trivial code changes, such as comments, broken tests or type corrections, and which do not require a code review, effects this system too. Analyzing a task for Peer Code Review is as important as the task itself and managers have to bear this in mind while tasking someone for a code review.

Another pertinent factor about this is that the service engineer reviewing a code has to be adept with all nuances of code-writing, and therefore, it is recommended that they not only docode review together but also execute hisown code during testing, and working in teams of two.

Optimizing Time

Doing a code review can sometimes take about 30 minutes to an hour a day, especially if the reviewer is also to perform secondary activities. But, when compared to benefits accrued, this process utilizes review time over time spend for fixing and patching, quite literally.

System Susceptibility

In few cases it may be possible that the person making code changes is the only one working in that domain and subsequent review-task is assigned to someone unfamiliar with those protocols. In such a scenario it is advisable to insist quality engineers to be diligent in their QA process.

In another case when this system may face hindrance is, when a reviewer is too busy with secondary tasks, allowing him only a superficial scrutiny, and thereby impacting the review quality. There can be possible solutions to this flaw, one is by outsourcing reviewing to a subsidiary company or multi-task etc.

Summary

Code Review is a mandatory step that teams should incorporate in their software delivery processes. It not only helps efficient software implementation but also helps minimizing bugs and maintaining highquality software, besides saving on repair costs.