The Power of Code Review: A Collaborative Approach to Better Code

8 min readAug 9, 2023

Code review is a crucial part of software development, but it can also be a challenging and time-consuming task.

Code review is a process of examining and improving the quality of source code written by software developers. It is an essential practice for ensuring that the code meets the standards, requirements and best practices of the project. Code review can also help to identify bugs, security issues, performance problems, design flaws and other potential improvements.

Code review can have multiple benefits:

Improving the quality and reliability of the code by finding and fixing bugs, errors, vulnerabilities, and performance issues
Enhancing the readability and maintainability of the code by enforcing consistent coding standards, style, and best practices
Increasing the knowledge and skills of the developers by learning from each other’s feedback, suggestions, and critiques
Fostering a culture of collaboration and communication among the developers by exchanging ideas, opinions, and perspectives

Types of Code Review

Formal Inspections

Formal inspections are a structured process that involves a team of reviewers who follow a well-defined checklist of quality criteria, design standards, and coding conventions.

Formal inspections are usually done before the code is tested or integrated, and they require a lot of preparation and documentation.

The formal inspection process consists of a few main steps:

Formal inspections have benefits for software development projects however also have some challenges and limitations

Therefore, formal inspections are not suitable for every situation and should be used selectively and strategically.

Some factors that may influence the decision to use formal inspections are:

The size and complexity of the code change or module
The criticality and impact of the code on the functionality, performance, security, or usability of the software
The maturity and stability of the code base and the development process
The availability and skill level of the reviewers and the author

Therefore, formal inspections are not suitable for every situation or project. They are best used for critical or complex pieces of code, where quality and reliability are paramount. They are also more effective when they are done regularly and consistently, following a clear and agreed-upon process.

Peer Review

Peer review is a type of code review that involves at least two developers who examine each other’s code and provide feedback on its quality, readability, functionality, and adherence to standards. Peer review can be done in various ways, such as pair programming, pull requests, or formal inspections.

Follow the Best Practices for Peer Review:

Collaborative Coding: Pair Programming

Pair programming is a type of code review where two developers work together on the same codebase, using one computer and one keyboard. The idea is that one person, called the driver, writes the code, while the other person, called the navigator, reviews the code and provides feedback. The roles can be switched frequently to balance the workload and share the knowledge.

Pair programming can be done in different ways

Driver-navigator: One person writes the code (driver) while the other person reviews it and provides suggestions (navigator). They switch roles periodically or when needed
Ping-pong: One person writes a test case (driver) while the other person writes the code to pass it (navigator). They switch roles after each test case
Remote: Two people work together on the same code using online tools such as screen sharing, video conferencing, and chat

To overcome these challenges, pair programmers should follow some best practices

Agreeing on the goals and scope of the task before starting
Choosing a suitable pair programming tool that supports real-time collaboration
Establishing clear roles and expectations for each partner
Switching roles frequently to avoid fatigue and boredom
Communicating effectively and respectfully with each other
Giving and receiving constructive feedback
Taking breaks

Collaborative Coding: Mob Programming

Mob Programming is a type of code review where a group of developers work together on the same codebase, using one computer and one screen. The idea is to leverage the collective knowledge and skills of the team to solve problems faster and produce higher quality code.

Trunk-based development is a software development practice where code reviews are conducted synchronously. In this approach, all developers work on the main branch and frequently commit their changes to it. One example of this practice is collaborative programming, such as pair and mob programming, which was introduced as an Extreme Programming technique by Kent Beck in the 1990s. It is based on the principle of “the more, the merrier”, meaning that having more people working on the same problem can lead to better solutions and faster learning.

Mob Programming is a type of code review where the whole team works on the same piece of code at the same time. It is based on the idea that many minds are better than one, and that collaboration and communication can improve the quality and speed of software development.

In Mob Programming, the team gathers around a single computer and keyboard, and takes turns to write or edit the code. One person, called the driver, is in charge of typing, while the others, called the navigators, provide suggestions and feedback. The role of the driver rotates every few minutes, so that everyone gets a chance to contribute.

The roles in Mob Programming are:

Driver: The person who writes the code, following the instructions of the navigator. The driver does not make any decisions on their own, but acts as a smart keyboard for the navigator
Navigator: The person who guides the driver on what to write, using high-level instructions and avoiding low-level details. The navigator also checks the code for errors, bugs, and style issues
Mob: The rest of the team members who observe the driver and navigator, provide feedback, ask questions, suggest ideas, and help with research and documentation

The basic rules of Mob Programming

Mob Programming follows a simple process:

Tool-Assisted Reviews and Automated Testing

Tool-assisted reviews and automated testing are complementary techniques that can enhance the effectiveness and efficiency of code review.

They can help developers to find and fix errors early in the development cycle, reduce the manual effort and time required for code review, increase the consistency and maintainability of the code, and ensure that the code meets the quality and security standards.

Therefore, tool-assisted reviews and automated testing should be used as a complement, not a substitute, for human reviews. Human reviewers can provide valuable insights, perspectives, and judgments that tools cannot. Moreover, human reviewers can also learn from the tools and improve their own skills and knowledge.

Code Review Pyramid

Best Practices for Code Review in General

Regardless of the method you use, here are some general tips for doing code review effectively:

Define clear and realistic expectations for the code review process

What is the scope, purpose, and goal of the review?
How much time and effort are expected from the reviewers and the author?
What are the criteria and standards for evaluating the code?
How will the feedback be delivered and resolved?

Know what to look for in a code review

You should focus on the following aspects of the code:

Functionality:

Does the code do what it is supposed to do?
Does it handle all possible scenarios and edge cases?
Does it have any bugs or errors?

Quality:

Does the code follow the coding standards and best practices of your team or organization?
Is the code well-structured, organized, and formatted?
Is the code easy to read, understand, and maintain?

Performance:

Does the code run efficiently and fast?
Does it avoid unnecessary computations or memory allocations?
Does it use appropriate data structures and algorithms?

Security:

Does the code protect against common threats and vulnerabilities?
Does it use secure protocols and libraries?
Does it handle sensitive data properly?

Testability:

Does the code have adequate tests to verify its functionality and quality?
Are the tests clear, concise, and comprehensive?
Do they cover all possible cases and scenarios?

Build and test before review

You should always make sure that your code compiles, runs, and passes all tests before submitting it for review. This will save time and avoid frustration for both you and the reviewers. You should also run any static analysis tools (such as linters, formatters, etc.) to check for syntax errors, style issues, or potential bugs.

Review the code in small and manageable chunks

Avoid reviewing large and complex changes that can overwhelm the reviewers and the author. Instead, break down the changes into smaller and simpler units that can be reviewed more easily and quickly. Use tools such as pull requests, branches, commits, diffs. to organize and track the changes.

Give feedback that helps (not hurts)

When reviewing someone else’s code, you should always be respectful, constructive, and specific. You should avoid personal attacks, sarcasm, or harsh criticism. You should also avoid vague or ambiguous comments that leave room for interpretation or confusion. Instead, you should provide clear and concrete suggestions on how to improve the code, with examples or references if possible. You should also explain why your suggestion is better than the current code, and how it will benefit the project or the team.

Communicate goals and expectations

Before starting a code review, you should make sure that both you and the reviewers are on the same page about the purpose, scope, and criteria of the review. You should also agree on how to communicate during the review process (such as using comments, chat messages, video calls, etc.), how to resolve conflicts or disagreements (such as using voting, consensus, or escalation), and how to follow up on the feedback (such as using action items, tickets, or checklists).

Include everyone in the code review process

Code review is not only for senior or experienced developers. Everyone can benefit from participating in code review, regardless of their skill level or role. Code review can help junior developers learn from senior developers, senior developers mentor junior developers, and peer developers exchange ideas and insights. Code review can also help non-developers (such as product managers, designers, testers, etc.) understand the technical aspects of the project and provide valuable feedback from different perspectives.

Foster a positive culture

Code review should not be seen as a chore, a burden, or a punishment. Code review should be seen as an opportunity, a benefit, and a reward. Code review should not be used to judge, blame, or shame. Code review should be used to learn, improve, and grow. Code review should not create fear, stress, or resentment. Code review should create trust, confidence, and respect. Code review should not be a one-way street. Code review should be a two-way conversation.

Automate to save time

While human feedback is essential for code review, some aspects of code review can be automated using tools and technologies. For example, you can use tools to:

Format your code according to a consistent style
Check your code for syntax errors, style issues, or potential bugs
Run your tests and measure your code coverage
Analyze your code for performance, security, or complexity issues
Generate documentation or reports for your code

Conclusion

Code review is a valuable practice that can help you improve your code quality, security, performance, readability, and maintainability. It can also help you learn new skills, collaborate with other developers, and deliver better products.