Do not Troll Your Teammates: 5 Key Rules for Reviewing Code

Code review is an essential step needed for effective software development.

By checking the code, the team's specialists and the project management team can leave their comments, corrections, and suggestions before moving forward.

Frequently the GitLab and Git version control systems are used to correct the code.

The turning point in creating a functioning code is its analysis. It is a process where suggested changes by an engineer can turn into inspiring the team to create a central codebase. This is the most important part of the process. If there are errors, the team bears the responsibility instead of an individual.

It is extremely important to check your code, especially when all work is done remotely. A team with effective code review gains the following benefits:

• The attraction of new developers;

• Adherence to industry standards;

• Creation of high-quality and reliable software, etc.

  
  

To become an experienced software engineer, you need to be able not only to write code but also to perform competent code reviews. If, when checking the code, you most often click "Approve"” then you should familiarize yourself with the fundamental rules for its checking!

1. Share Your Thoughts

When taking part in code review, be critical. If a beginner does not understand how the code is made, he should not be silent. He must express his bewilderment.

Before submitting a merge request, contact your team in any way convenient for you, whether it’s via messenger or e-mail, and tell them what worries you, what is not clear to you.

There are situations when even experienced senior developers require an explanation of some points in the code's development. The solutions can be simple.

For example, to perform a complete refactoring of algorithms, or vice versa, it is easier to add a comment to perform manipulations with bytes. These comments will be important to your team at this stage.

Let's imagine the following situation: Senior developers at your team found a mistake or did not understand something in the merge request and remained silent. They did not tell you about it. Surely you understand what the consequences can be!

Therefore, it is so important to voice your thoughts. Team members functioning with various levels of misunderstanding, especially by junior developers, can lead to serious consequences and further disruption of the code.

2. Understand the Acceptance Criteria (AC)

You can understand this rule in different ways.

Typically, you need to know and understand the objectives and fundamental goals of a merge request. You also need to understand if you can achieve these goals if you make certain code changes.

If you are using AC in your work, it is important to detail each level of abstraction. What can you do to understand the AC?

View the ticket associated with the Pull Request. There you should find a detailed description of the general details and goals of the implementation. There are two paths of development here. The first one is for someone who views merge requests. The second is for the authors of the merge request.

Be sure to leave additional information, point out any errors in the description of the merge request. Even if you leave your comments on your MR if you see confusing snippets, it will help your team greatly in further work on the code.

3. Make the Least Amount of Changes

Will others be able to check the code efficiently if they open a merge request and see that it contains over 1000 lines? Of course not. No team member will see it all.

The Ideal MR is 10, a maximum of 100 lines of code.

If this scares you, don't worry. Follow the practical advice on how to perform a quick and short code review.

First, check that the .gitignore file is correct. This file warns the Git version control system about all files that should be ignored. These files can be based on dependencies resulting from using the Angular web framework or linked to your IDE.

Use a repository of useful .gitignore templates. This will make your work much easier.

Second, promote daily code reviews. Using GitLab, change the MR title, start with "WIP" (work in progress) or "draft”.

How does this help your team? They will study and comment on code changes, but with a limitation. You cannot merge into the desired branch. This method will increase your team's awareness of the changes you make every day.

They will not have to perform gigantic checks of 1000, which means they will increase the efficiency of teamwork and understanding of the codebases they work with.

4. Make the Team Standards Clear

What is the minimum code coverage threshold? Does your team use underscore_case or camelCase for Angular? Do you have a special place for common functionality and code? Does your team have a function line constraint to facilitate testing?

If you are part of a team, you know the answers to these questions. For software development best practices, we encourage your team to keep a dedicated journal to document standards. Take the time to make such a manual yourself. This will help your team document their standards and practices.

5. Find the Balance

Code review is not a simple task. You must be clear about your work and answers.

Do not troll your teammates.

Respect each member of the team who attempts to do their job, even if sometimes it is of poor quality. Be proactive.

Code reviews are a process where part of the team praises their achievements, and the other hates opponents. But when the code review is completed, you will become one whole, where all team members will be to blame for making a mistake.

Conclusion

Thank you for taking the time to read this article on code review.