How Code Reviews work in a team?

So, what exactly is a code review (or inspection)?

The definition of code review or peer review in Wikipedia is as below,

Code review (sometimes referred to as peer review) is a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the person must not be the code's author. The persons performing the checking, excluding the author are called "reviewers".

As a programmer, you always try to write the code to the best of your ability, but still every time you look at the code, you find some opportunities to make it better (refactor). The code review or peer review is another mechanism to improve your code where another developer looks over the code and visually identify the any number of potential trouble spots like memory leaks, scalability, or maintainability issues etc.

So, what's the purpose of code review?

• trying to catch defects?
• does the new code conform to existing enterprise coding standards?
• are there any obvious logic errors in the code?
• looking for functional omissions?
• teaching and sharing the knowledge between the developers?
• checking code formatting?
• checking for adequate code comments?
• sniffing out code smells and design faults?
• checking that non-functional quality requirements are met?
• are the new automated tests sufficient for the new code?
• is it maintainable and scalable?

You may have another purpose not listed here. Meeting each of these different objectives requires different techniques, attention, skill, and knowledge. When you use the term "code review" (or "code inspection", or "peer review"), make sure everyone sees it the same way.

There are various common code review approaches,

Pair Programming: The practice come from the Extreme Programming (XP), this approach to writing software, developers works in a pair, working on the same code together and thereby checking each other's work as they go. It's also a good way for senior developers to mentor junior colleagues and seems to bake code review directly into the programming process. Yet because authors and even co-authors tend to be too close to their own work, other methods of code review may provide more objectivity.

Over-the-Shoulder: More comfortable for most developers than XP's pair programming. Once your code is ready, just find another team member to review your code for you, as you explain to them why you wrote it the way you did. This informal approach is certainly "lightweight", but it can be a little too light if it lacks methods of tracking or documentation.

Team code review: The approach is used to review a critical piece of code as a team monthly (or in an agreed cadence) where everyone shares the improvements can be made to the code. This works well to educate the team on writing a better code, but may be too late in the development cycle to make timely corrections to the code.

Tool-Assisted: Code review tools, some of which are browser-based or seamlessly integrate within a variety of standard IDE and SCM development frameworks. These tools can find hundreds of code vulnerabilities in a large chunk of code.

So, another important question is should we do manual or automated code reviews.

Manual Vs. Automated code reviews:

When it comes time to choosing the tools and processes you'll use to conduct a code review, you may stumble upon the question of which tools to use and whether you should use automated tools or manual inspection. Which is better? As with other areas of your SDLC, the best approach is a mixed approach, combining both manual review as well as inspection using strong static code analysis tools. Automated code reviews help in detecting in low hanging fruits and hundreds of other vulnerabilities, a large chunk of code can be tested quickly on-demand. On the other hand, manual code reviews help to deep dive into the code paths to check for logical errors and flaws in the design and architecture most automated tools couldn't find.

Team Agreements:

The code review process should be understood and agreed by everyone in a team. Assuming the team wants to connect code reviews, they need to make agreements:

• What code review is automated vs manual?
• Does the developer apply the findings straightaway?
• Do some findings end up on the backlog? Which ones?
• Who prioritizes the findings?
• No personal attacks

And so on. Once the team has made these agreements, they become part of the definition of "done" (DOD). From now on, being done with a story implies that it's been reviewed, and the results of the review has been processed accordingly.

How to ensure that code reviews don't become impediment?

A central point of Agile is to shorten feedback loops. Reviewers (who are often tech leads or other senior folks) may take longer to complete tasks, if they delay reviewing, the developer who thinks he has finished a task has to wait instead. If he doesn't wish to wait, he switches context to other things, and later will pay switching cost when the review result comes back. Ideally, any developer who thinks he's done with a story should be able to say so and move on. And ideally, reviews should be done quickly and without burdening the reviewers. By the way, that's one reason for pair programming with frequent pair switching; it manages the downside of code reviews, while amplifying communication and learning among those involved.

In many teams, the technical lead performs all the reviews. That makes the lead a single point of failure and maximizes the delays, because leads tend to be busy. In my experience, few people enjoy reviewing other's code, so they just give it a superficial look. However, if your team needs to conduct code reviews, I suggest that they distribute reviewing duties among all members.

To conclude, create a culture of reviewing code takes time and effort. An apt parallel from the book writing to software development is,

Authors need editors to catch mistakes. It is human nature that one cannot adequately proof-read one's own work. Authors of software need the same assistance as authors of novels to achieve the goals of the software organization.

No one will deny the fact that the code reviews are essential in a software development process to get an early and timely feedback on the code to avoid the risk of unstable, high maintenance, unscalable, and unreliable software. At the same time, it's equally important to act on feedbacks in a timely manner to make the process worthy.

Please do share your thoughts and feedback!