Do code reviews matter?

On January 15, 1990, over 50 percent of AT&T’s network crashed. In nine hours, 75 million calls went unanswered. An error in just one line of code brought down AT&T’s network for several hours. A switch reset itself, but the bug meant that the second switch sent another message. Essentially a domino effect kicked off with the network continuing to repeat its error.

Despite heavy testing, a single line of code crippled the whole network. The program was written in C. A minor deviation from standard coding guidelines caused this issue. Today at KNOLSKAPE, we can catch these issue with single click of a button.

How do we avoid such issues? The best way would be showing the code to multiple developers and gather feedback. In this process, one of the developers would point out the potential issue. Process of showing code to another developer and gathering feedback is called a code review. Let’s start with understanding what happens in a code review.

What happens in a code review?

Once a developer completes implementation of a feature, Following are the steps that are performed as part of the code review at KNOLSKAPE

• Step 1: Tool based review — Reviewer looks at the status report generated by a static code analyzer. This step helps in getting an idea about basics of the code like syntax errors, documentation ratio, coding guidelines etc. In most cases, these are categorized as bugs, vulnerabilities and code smells.
• Step 2: Retrospect — Reviewer will verify the implementation of the changes suggested in the previous reviews.
• Step 3: Walkthrough — Code walkthrough from the developer. This helps reviewer to understand the overall structure of the code for a specific feature.
• Step 4: Review Architecture — Understanding of architecture to evaluate modularity and flexibility. Once a reviewer is able to understand the architecture of the feature, he/she will be in a position to judge whether the implementation is modular and flexible for upcoming or expected changes.
• Step 5: Review Logic — Reviewer looks at the logic, data structures, design patterns used for implementation. This step will help in improving the performance, reliability aspects of the application.

At each step, the reviewer would give his/her feedback and suggestions on improving the implementation.

Types of code reviews

The email thread — Code is shared over email. Comments, suggestions etc are communicated through email itself. The downside of it is, we can’t generate stats of reviews.

Pair programming — Two developers sit side by side, working on the same code together and thereby checking each other’s work. This approach is faster but is only when one of the developer is senior.

Over the shoulder — Once a developer is ready with his/her code, they call their colleague to review their code. Both developer and the reviewer go through the code together. Review comments are often noted down manually.

Tool-assisted — Making use of software-based code review tools to review the work. These tools help us in performing static analysis on the code. By static analysis, we can validate and verify the coding guidelines. However, validation of logic will be done manually. We at KNOLSKAPE use a tool called SonarQube for the static analysis.

Benefits

• Readability. What good is your code when others in your team can’t understand it? Readability is one of the metrics used for measuring the quality of the code. Code reviews help you to get your code validated on readability and understandability. Often team adheres to coding guidelines set by the company/team. During code reviews, the reviewer would validate on the adherence to guidelines.
• Opportunity for senior engineers to mentor. In current world, requirements change frequently. The code should be flexible to adapt to these requirement changes. Senior engineers often have experience in dealing with such use-cases. These folks can mentor juniors on making their code flexible to requirement changes as part of the reviews.
• Learning and sharing. Code reviews help you to learn implementation techniques from your peers and also enables you to share your thoughts with your peers on implementation details. This can lead to quality discussions on improving and optimizing multiple things like performance, security, etc., that go into an application.
• Reduces operational cost. Having code reviews as a compulsory process will ensure there is always a developer who doesn’t need a detailed knowledge transfer at the neck of the moment to fix any issues or to develop new features.
• Boosts confidence in developers.

What is not a code review?

• Code reviews are not meant to criticize others, they are focused on understanding the rationale
• It is not to tell something is wrong, they are for improving the existing solutions
• Only senior engineers can review the code? No, anyone can review other’s code. Never hesitate to read, review your senior’s / peer’s / junior’s code
• Whatever is suggested in the review is final? No, they are iterative as well. As the application grows there could be better ways of implementation
• Reviews are not one way communication, they are always interactive. Both developer and reviewer will contribute in the reviews.

How did code reviews help us at KNOLSKAPE?

• We, developers, started discussing design principles and patterns. This helped us in developing enterprise grade application in short span of time.
• Started to identify common features across the products. This helped us to build a boilerplate template(knolgen) for upcoming products. This reduced our effort by couple of weeks for each project.

Going forward, we definitely need to integrate code reviews in our development process in a more disciplined way. We need to graduate to an advanced level, where we discuss architecture and design patterns more than guidelines and logic.