Code Review: Trendyol Search Core
Code review is crucial in software development and ensures code quality, collaboration, and project success. This article outlines the Search Core Team’s specific approaches and provides insights into maintaining high-quality code and fostering collaborative development.
What is the Code Review?
Code Review is the name given to the process of reviewing the development of a project by people other than the developer before the development is taken into the codebase.
It is one of the most important processes in the software development cycle. It is important in ensuring code quality, collaboration, and overall project success. This practice involves the review of source code by members of the team to identify defects, improve code maintenance, and ensure compliance with coding standards.
The cost of solving problems when there is no code review or when it is not done regularly can be much more than regular reviews. In a way, we have a proactive process in our software cycle and take precautions before making a mistake.
Code Review Flow
The Code Review process starts when the developer prepares the Merge Request (MR). Preparing to start the Code Review process allows developers to check and produce better-quality work.
While preparing MR in our Search Core team, we use a template that summarizes the change with an explanation about the development, which improvements have been made, which improvements have been made, which information is necessary for the testing process, which is our next stage, and where we can note general reminders.
The flow continues with sharing the MR with reviewers. Then, approval is expected from the reviewers up to the number of mandatory approvals, 2 approvals are a must for Search Core. If the reviewer has a comment, they send it to the developer via MR. This way, comments, and responses are recorded and can be accessed when necessary.
If the developer finds the comment reasonable, they can change it or make a counter comment. This cycle continues until the two parties agree. If there are any unresolved comments, the code cannot be merged. After the review process is completed, the flow continues with the test phase.
Best Practices
There are two parties in the Code Review process, the developer and the reviewer. Let’s see how the best practices of this process should be for both parties separately.
Best practices that the developer should follow; code changes should not be too long, this reduces the readability and review quality of the code. Unit tests should be written, and developments whose tests are not written or not fully covered are rejected by SonarCloud, which also allows us to measure code coverage. Ensuring that the tests are readable and understandable and that the code is robust is one of the points we pay attention to when reviewing. If you want to learn more about Unit Tests, you can read my article.
A review can be requested from the person who is considered to be an expert on that subject for the development made, we do this when necessary to release safer code. If the review process of a development is prolonged, a gentle reminder can be passed, and the developer should follow the completion of the review.
If comments are received from reviewers, they should be responded to as quickly as possible. For long or complex developments that are difficult to review, a team review can be done, when we realize this, we hold a team meeting to review more effectively. If the two sides disagree on a comment, the developer and the reviewer can talk or get ideas from the team, after they agree, they can resolve it by writing the result in the thread.
Best practices that the reviewer should follow; they can ask questions until they understand, this is the way it should be. However, the review of the overall structure or design of the work should not be done at this stage, it should be agreed on beforehand and the development should be started in this way.
Reviewers should focus on:
- Has the development been done in the way it was expected to be done? Does it match the task details?
- Have coding standards been followed? Is the development sustainable/readable? Have the standards of the project been followed? Development can be done in many ways, the important thing is to continue by the standards.
If the above items have been completed in the development and there are no performance and complexity issues, it should respect its progress. The reviewer comments should be made at once, approval is expected after the comments are resolved.
Both parties should be understanding towards each other in this process. The Code Review phase, which is one of the most important parts of the software development process, should be considered as a process that ensures that the team’s work is completed in a more error-free, sustainable, and readable manner, and should not be perceived individually. I would like to conclude this title with the following quote;
If you are in the middle of a focused task, such as writing code, don’t interrupt yourself to do a code review.
Benefits of Code Review
So far we have talked about how to do Code Review better and what to pay attention to. Now let’s examine the benefits of doing Core Review.
Durability means that if there is a bug, it is detected before the development code is merged into the base.
With knowledge sharing, reviewers can better learn business, technical, and project code standards. Everyone on the Search Core team has the role of a reviewer, and I experienced the benefits of reviewing as part of onboarding when I first joined the team.
Quality, Code Review creates a sense of responsibility and a desire to check the development before sharing it with the team, to write more readable, maintainable code. If there is an overlooked point, reviewers detect it and high-quality code is included in the codebase.
Sociability, developers, and reviewers communicate during Code Review, sometimes there is an opportunity to meet different teams.
Recording keeps track of which improvements were made and why, what comments were received, and how they were resolved, so that we have a resource to look at in the future.
Code Review at Search Core Team
Up to this point in the article we have talked about the practices we use in our team from time to time, now let’s talk about the key points that we use and that have been effective for us.
Everyone involved in the Search Core team has the authority to review/approve. This responsibility enables reviewing and naturally increases the benefits such as knowledge sharing and social effects mentioned above.
We have identified a development point that prevents us from conducting effective reviews. We realized that these MRs cannot be seen when they are shared from our Slack and we started to use a Slack channel to share only MRs. After the developer shares the MR link, reviewers indicate the status as In Review, Commented, or Approved. In this way, we start the review process more effectively and faster.
We aim to complete the works that come to Code Review status within an average of 1 day, the developer can make his reminder, or thanks to a webhook we have created, a message regularly reminding the works in Code Review status come to our review channel. As a team, we allocate certain time intervals during the day to review.
If we have a different code suggestion, we throw it where we see a development point with GitLab’s Code Suggestion feature and it helps us reach a solution faster.
Conclusion
This article is about the general Code Review processes, which problems we solve as the Trendyol Search Core team, and how we carry out this process. You can also get more information by following our Trendyol Medium account.
Thanks for reading the article, you can contact me for your feedback and questions. See you in my next articles!
#ComeToTrendyol
If you want to make a new start in your career and join us, you can access the open positions from the link below.
