On 9th September 1947, operators tracing the source of errors in a Harvard Mark II system discovered a moth trapped in a relay. Even after three quarters of a century later, many a brilliant software engineers spend fretful nights dreaming of a foolproof ‘debugging’ strategy. At first, codes are created, but they have many vulnerabilities, errors and loopholes. In order to kill these ‘bugs’, an efficient strategy is needed, and this is where code reviews come in.
Code Reviews are basically checks conducted on a software code ensuring that they comply with the standard conventions, formats and protocols. They should stand the analysis in terms of proper functioning, operation and possible security threats. They are broadly classified into:
The conventional formal approach is very thorough and rigorous, but the rate of review is very slow; for two hundred code-lines, we need approximately 9 man-hours. In this digital age of super-speed, this proves to be a rather serious drawback and renders the approach impractical. As such, a paradigm shift is required and this is provided by lightweight reviews of source code.
The methodology called Lightweight Code Review enhances the practical effectiveness of the code review process, especially in a high efficiency environment. It comprises of four procedures:
- Over-the-shoulder: It is like when you are performing, you have done your school homework and you are now explaining it to your buddy. You will take him through the program while he may interrupt your speech and thought flow with doubts and queries. In today’s age, the reviewer does not need to be physically present. Skype (or even a simple telephone) enables him to call you up regarding the procedure as he looks at your program from miles away.
- Email pass-around: As the name suggests, the code is emailed to the reviewer. He reads them at his own pace and clarifies his doubts with the developing team.
This too is easy to operate and independent of distance and unlike the first, the reviewer does not have to adjust to the author’s pace. But there is always the problem of enforcement and the fear that he might have just deleted the emails. There really is no way to know when the review is finally over.
Two programmers simultaneously work on the same computer and cover each other’s backs. Just one employee types at a time raising questions of lessened productivity, albeit knowledge-exchange occurs.
Some programmers prefer it while others simply do don’t. Some believe that review time is saved while others believe production time is wasted. Some see the closeness as an asset; some see it as a liability. It fails to cater to remote-reviews.
It involves commercially available tools like Automated File-Gathering , Clients and Integration, Automated Metrics Collection that can be combined with the above measures. Cost effectiveness needs to be ensured.
All of these processes surely give rise to a practical comprehensive code-review paradigm.
About the Author: This article is written by Tom Rhoddings.