Importance of Code Review and Testing in Software Development

Despite being an essential component of every software development project, code reviews sometimes get overlooked or mistaken for code testing. Read on to learn about the difference between the two and why code reviewing is so important to software delivery processes.

For some, code reviews might seem a little controversial. Since you have a team of the best specialists, you should assume that they do their work in the best possible way. But if we consider the similarities between building a city and software development, we can also notice some similarities in this case.

Even if a team consists of the best builders who perform their duties carefully, in the end comes a time for control. When a building is done, especially if the construction is designed for a large number of people, an independent inspector verifies if what was built complies with all requirements and regulations. In most cases, it will only be a confirmation that everything is fine. But there’s always a chance that the inspector finds something that doesn’t meet standards. Thanks to this stage, the problem can be resolved immediately, preventing a poorly made construction from being used by end-users or causing problems for people finishing the interior.

It should be the same with software development. Even if there is mutual trust within a team, checking someone’s else work is invaluable. Some mistakes or problems might occur even if your whole team is highly experienced. These can result from someone having a bad day or being in a hurry. By verifying that everything is done correctly before the work is considered done, such problems are found before the code is deployed anywhere. This way we can improve it at a low cost and minimize the time needed for repairs. This stage of “inspecting” the code before it reaches users is called “code review”.

Why are code reviews so important?

We have all heard stories of projects where one person does a fragment of the work completely independently and when he/she left the company or just had some time off, the rest of the team faced challenges since they were unfamiliar with this part.

Perhaps the code deviated from generally accepted standards, was atypically written or simply nobody knew what was actually going on with it. This situation is a perfect example of a problem that arises when there is no code review in a project.

Even if a team has specific standards that each team member knows, there is a chance that they will produce code that can be done better or in a more accessible way. Lack of code review speeds up the code degradation process. Having less control over what our teammates did means that individual fragments can go in other directions and consequently lead to a situation where the code is written in different ways, depending on who was responsible for a particular part.

But keeping a finger on the ‘quality pulse’ is not the only goal of this process. The presence of a code review in teams’ work is also a great way to exchange knowledge. If we include this process, we avoid a situation in which only one person in the team knows a given piece of code.

Code review is also a great way to spread business knowledge. By doing code reviews, we discover other parts of a system and learn not only what they are responsible for, but how they work. The process gives everyone in a team a chance to have similar business knowledge and be familiar with all parts of the application they are building.

What does a code review look like?

As for the code review process itself, it partially depends on the team involved. For example, what formal rules are needed, what the entire code delivery process looks like and developers’ level of experience will all impact the shape a code review takes. However, we can highlight a few common traits of all code reviews.

First, a reviewer checks if all names and instructions are understandable. Therefore, it is important that a code review is done by someone who wasn’t involved in creating this part of the code. A reviewer should be able to grasp the idea by only reading the changes that a developer made. If anything is incomprehensible, a reviewer can report it immediately. Thanks to this, we quickly remove something that may cause a problem in the future when other people will have to read this code and understand what its author included in a certain fragment.

The second reason for running code reviews is compliance with agreed standards. An experienced team always has a set of rules that influence how its members write code. These usually include elements like naming, usage of external libraries, ways of dividing parts of the project into specific areas, writing tests and document changes. We assume that everything developers write and add to the common code should comply with all these rules. But no one is infallible. Occasionally someone forgets something or does something in a way that deviates from the established standard. And thanks to code reviews, another team member can spot such problems and immediately flag them to the author so they can be addressed.

As for the process itself, it all depends on what your project and the entire code delivery process look like. But in most cases, if a team is mature and has processes for all stages of code delivery, a code review is done after a developer finishes adding changes and makes these available to others in the form of, for example, a pull request. Then selected people, or simply someone else from the team, can review the changes and add comments. This is facilitated by tools that are available in all popular repository management systems, such as Azure DevOps, GitLab, GitHub, and BitBucket.

Some teams decide to go one step further. If an application can be easily run on a work computer, they agree that some – one should pull changes and try to run the app at home. Then they can also catch problems like “I changed something on my machine but I didn’t add it to the commit and delivered the code without this element”. You can also add a rule in your repository that you can create a request for code review only when the code has been successfully built and tests have revealed a positive result. Thanks to this, you immediately avoid the problem of missing changes, without having to build and run each change that you check.

You’ll find four fascinating in-depth articles similar to this one in the  “5 Steps to a successful software development project” ebook.

Should code reviews be official and formal?

Until now, this text presents a code review as a formal process that has predetermined rules and is a ritual that everyone must carefully follow. But it’s not completely true.

A code review can be something that a team does without special tools or written rules. In its essence, a code review is, primarily, another person’s view of the code created by another developer.

If a team is just starting to do code reviews, it may be enough for one person to write to another that there are changes in one of the branches that need to be checked. It may also happen that the code will be reviewed by several people and each of them will pay attention to something different. At first, a team would probably not have a formal list of what to check. And this way they will naturally work out such a list, even if it will never be officially written down.

Code reviews should not be burdensome for the team, but rather, a natural part of the work. You can even go a step further and say that the more formal the code review process is, the more energy it will require from programmers, making them feel discouraged, or prolonging the entire process. If the formalities themselves take an additional few minutes and someone will have to fill out a few forms, the team will slowly try to limit checking or introducing changes since there are changes that can be checked in a dozen or so seconds. For example, if someone finds a bug that can be quickly fixed, they will consider whether it is worth changing it immediately, as then they will have to go through an overly complicated path of approving changes, even if the fix will require just two lines of code.

But we also have tools that can facilitate code review. These can take some of the responsibilities away from developers and be used to automate, for example, checking generally accepted code writing standards. Static code analysis tools, such as SonarQube, can confirm whether all rules have been followed, including: spacings in key places, naming rules and certain language elements. But these can also automatically verify much more complex problems, such as some application security issues. Static code analysis tools can detect some of the problems and report if a system is not secure enough. If we determine that a code review will be done only when such a tool gives a positive result, then during manual code reviews we can focus on transferring knowledge about the project, implementing logic and creating a correct solution for the problem at hand.

“We have tests, so we don’t need a code review”

One of the code review myths is thinking that if there are tests in a project, there is no need to do a code review. It results from a misunderstanding of what a code review is responsible for. It’s not a process whose main task is to catch errors in logic. This is what tests do.

The essence of a code review is to verify the quality of the created code as described in previous sections. When it comes to tests, developers can also perform a review to check whether these were actually written and whether the code they provide maintains the agreed standards.

You can have code covered with tests, but it still might be difficult to maintain, inconsistent with set standards, and above all, incomprehensible to other team members. The only way to eliminate these problems is by running a code review. Automatically running tests, no matter how good they are, will not give you an answer to whether the code is readable and has all the elements it should have.

A code review is therefore a supplement to the tests and another element in the feedback loop, giving you information on whether what you are doing is correct. It should not be treated as a substitute for a test, and tests should not be treated as substitutes for code reviews.

Should everyone in a team do a code review?

Development teams are almost always composed of people with different experiences and consist of both seniors and juniors. It might seem sensible that only seniors, as the most experienced ones, can and should do code reviews for all members of the team. But it’s worth giving everyone this opportunity.

Not only because the working time of a senior is the most expensive, but also because code reviews done by juniors can also be valuable.

Why? Firstly, a junior can observe other people’s work and learn how the team performs tasks. When doing a code review, he/she has an isolated fragment and can be sure that the code he/she sees is entirely relevant to a specific task. This way a junior can gain insights about how another, probably more experienced programmer, has made necessary changes

Secondly, a junior, as a person who gained knowledge at a different time using other, often newer sources, may have a fresh perspective on a given solution. Seniors, like all people with more experience, may fall into a routine or repeat old habits for years. And a junior looking at their code can break this routine.

Junior developers might know another way to solve a problem or can start asking questions that will make a more experienced person think whether a given fragment cannot be made in a simpler way that’s easier to maintain. Thanks to this, code reviews done by a junior can contribute to the use of solutions which are easier to understand and beneficial for the further development of a project.

Code review – summary

A code review is an important element of software development. Omitting it, even if brings temporary savings, may cost a team much more time in the long run, and consequently, generate higher costs for a company.

Comparing the development of an IT project to constructing a building, we can say that a code review is a check of foundations, walls, or installations immediately after their completion – before the building is ready and put into use. So in case of any problems, these can be fixed immediately. If we can’t imagine handing over a finished building, knowing that no one controlled the subsequent stages of work on an ongoing basis, why should we accept the commissioning of an IT project in which the foundations or subsequent parts were not checked by someone as they were built?

Effectively conducting code reviews and verifying code quality requires the expertise, experience and best practices of a committed software development partner. Fill out the form and get in touch – our specialists are waiting to hear how they can help you achieve your business goals.