You have to choose between two apps with similar purposes. One of them constantly crashes and loading views takes ages. The second one works flawlessly. Which one would you install?
It doesn’t take an expert to understand that the first product won’t make a career. Users need stable apps that are regularly updated and enable quick execution of tasks.
But to make this happen, you need high-quality code. It makes the app function well, so it can ensure users with better experiences.
Code review is a solution that helps you reach this goal.
What is a code review?
Code review is the analysis of code written by another developer. The goal is to detect potential errors. After verifying the source code, the reviewer shares their observations with the author – both negative and positive ones.
What elements need to be verified? It depends on the team and project requirements. Nevertheless, developers usually try to find answers to some elementary issues:
- Does the code meet the team’s standards?
- Have all the cases been taken into account (especially the edge cases)?
- Are there any errors that are typical to this programming language or any logical errors?
- Do the implemented changes ensure top performance and stability?
- Is the code clear and easy to understand?
Nice to know When skimming through various articles, you may notice the term peer review. It’s a qualitative method of evaluation that applies to scientific achievements. In case of software development projects, peer code review means – same as code review – browsing the code in order to find errors. So, you can use these two terms interchangeably.
Why is the code review so important?
Code review is one of the basic elements of the continuous improvement process. What benefits does it offer?
- Improved quality of the code – code review allows us to take care of the app’s stability and increases the chances that users will enjoy it.
- Earlier detection of bugs – we can detect and fix many bugs before software testing starts. It allows you to save some time and money.
- Increased safety – code review increases the probability of finding critical errors that can impact the safety of the app’s next release.
- Consistency of code – this process helps us check if the code meets the team’s standards.
- Shared responsibility for the project – everyone in the team has an impact not just on their own code but also on the code written by other specialists.
- Knowledge transfer – this way, developers exchange info about new methods and tools. They learn how to write better code, search for alternatives, and get a good understanding of business problems.
- Fast way to get to know the code base – code reviews help new team members enter the project.
- Protection from the delays – the whole team is familiar with the code and knows what tasks are currently being developed. So, when one specialist is away, it doesn’t cause any delays in the project.
No one wants to be the only contact person when something goes wrong with the snippet of code. All the same, no one wants to work on a critical fragment of code they don’t know (especially, when there’s a crush on the production environment). Luckily, with code reviews we constantly exchange the info among team members. So, when one developer goes on vacation, they are replaced by someone who knows a lot about the project.
Code reviews allow you to save money
Why do we think that the sooner the bugs are detected, the better? According to IBM, it impacts the cost of the project. The lowest (basic) cost is at the designing phase. Then, it gets multiplied at every stage of the software development lifecycle, so the cost is:
- 100 times higher at the maintenance phase
- 15 times higher at the testing phase
- 6,5 times higher at the implementation phase.
What are the consequences of late error detection?
- Users uninstall the app or just stop using it.
- The app release cycle is delayed.
- Fixing the bug is a bigger (and more expensive) challenge. Often, it’s quite difficult to find out what’s causing the errors if they were detected long after their first occurrence.
To wrap this up, when the app is written with low-quality code, its development cost goes up.
Nevertheless, it doesn’t mean that code review has no flaws. Developers must spend some time on it, and it costs. The execution of certain tasks also takes longer. But you still have to remember that eliminating the errors at the early stage pays off in the long run. When we make such changes later in the process, they put a strain on the budget. Code review allows you to avoid them. That’s what makes it such an important element of the app development process.
Code review and unit tests
Some people mistake unit tests for code reviews. However, the differences between the two are quite significant.
Unit tests verify small fragments of code that are called units. Their goal is to check if every unit works as expected. We run such tests when writing the code of the app. They can be launched automatically.
Unit tests
- They let you find deeply nested and complicated problems faster than a reviewer because they rely solely on logical dependencies in small snippets of code.
- If done well, they can be used as documentation for other developers. When analyzing such tests, developers get to know what a given fragment of code should do.
- They enforce critical thinking about one’s own code when the author writes tests. Developer tries to come up with tests that would take into account all the cases – including those with errors.
Example Imagine that you write a feature that subtracts two numbers from each other. In order to test it, you enter letters or signs instead of numbers. This way, you can check if the obtained result is as you intended.
Code review
- Not only the author looks into the code, but also the reviewers. It makes it possible to detect bugs at an early stage. It also impacts the code quality and enables knowledge transfer within the team.
- Thanks to the code review, you can check if the new code is consistent with the team’s standards and whether the best solutions were used to write it.
- It enables you to verify if the unit tests were written correctly.
None of these solutions can be replaced by the other. You can only decide which one has a priority (and, for example, use unit tests only to check critical elements of the app). These mechanisms shouldn’t exclude themselves either. If you want to ensure the highest standards of the project, it’s best to use them both.
Types of code reviews
You can review the code in many ways. Take a look at some examples of available methods.
Tool-assisted review
At Holdapp, we usually choose asynchronous code review. It requires tools that enable browsing the code (e.g., GitLab). Such solutions facilitate developers’ work because they:
- automatically collect changed files and display the differences
- allow the exchange of messages between the author and reviewers
- let you evaluate the efficiency of the process with metrics
- increase the automation of the code review.
Pair programming
In case of more complicated problems, we turn to pair programming. This method involves two developers who cooperate with each other. One of them writes the code, and the other one reviews it, in real-time. They both share the same goal – to find the best solution to a problem. Pair programming is quite time-consuming, that’s why it is recommended for difficult tasks.
Over-the-shoulder review
It’s a synchronous type of code review. In this case, two developers work together – the author and reviewer. They both look at the shared screen. The difference between the over-the-shoulder review and pair programming is that the author writes the code earlier. During the meeting, they explain why they chose some particular solutions. The reviewer poses questions and shares their recommendations. Fixes can be implemented in the course of the review or later. This method is faster than pair programming but the reviewer doesn’t know so much about the code.
Email review
This method is rarely used because it only pays off in case of small problems and short fragments of code. Such review is based on the email exchange. This way, the developer sends the info about the changes to the entire development team. It usually takes place via the version control systems to automate the notifications. The email initiates the conversation about the code. Then, team members can recommend further changes, pinpoint the bugs, or ask for explanations.
When does the review take place and how?
At Holdapp, we run a review when the developer stops writing the code – but before it is added to the main code base.
First, the developer adds the code to the new branch. It is a separate place in the repository where you can safely work on the changes.
When the developer’s job is done, they open a pull request (a request to merge the code with the main base). It’s a way of informing others that the code is waiting for the review. Until they’re accepted, these changes in the code won’t have an impact on other tasks. It gives the reviewers as much time as they need for the verification.
After that, the code review process can run differently depending on the size of the project.
Case no. 1: Small projects built by one developer
The reviewers are people outside of the project. In most cases, they are developers who have some spare time, for example, after completing their tasks. Diversity of reviewers increases the chances of implementing good ideas that will improve the code.
Unfortunately, these reviewers often have minimal knowledge about the project, business goals, or API requirements. So, they aren’t always able to detect all the errors.
There are two ways of finding the reviewer. In most cases, someone sees the request and simply starts the verification. But if no one checks the code, after one day without a review a developer starts writing to other specialists asking them to look at the changes. There will always be someone to count on.
Case no. 2: Bigger projects created by two or more developers
Reviewers are those developers who are directly engaged in the project. Code review usually takes less time, because the people involved have an extensive knowledge about the project, business goals, and API requirements. It facilitates finding errors.
But it also means that knowledge transfer takes place between a small number of people. Hence, the recommended changes may be less creative.
In both cases, the number of reviews and the form of code review depend on the team’s standards and project requirements.
Holdapp teams always inspect all the changes. Even if just one line of code has been edited, we check it before adding to the main base.
Protection from the errors
Every team wants their apps to be of high quality. But in reality, we need to deal with limitations of time, budget, or engineering capabilities. You must also take human error into account. All these elements have an impact on the app’s performance.
Code review cannot guarantee that 100% of errors will be eliminated. But it should significantly minimize the probability of their occurrence. Regularity is essential here, but so is a well-designed process. All the team members must obey it. This way, your chances of creating a flawless app will significantly increase.
