Code Review Has Tricks That Only Experienced Developers Know About. In Simple Language, Code Review Can Be Likened To Basic Code Testing.

Thanks to this process, developers receive feedback on their code. This is why code review is a unique skill for software professionals.

It is interesting to know that we have methods for code review that every software developer does not readily share with others.

In the following, we will mention code review techniques so that you can deliver,r flawless codes thanks to them.

The first solution: offer to rebuild the code at the right time

At first glance, refactoring may not seem so important. However, a skilled developer will check that the code has been refactored. It is much easier to change code that has been rebuilt. To clarify this issue, consider the following examples:

First example: The developer writes a principle very similar to existing regulations. He may have copied and pasted these codes. Then the code reviewer offers to copy these codes again by moving them to another place so that this code can be used in both parts.

Second example: The developer has to do another project, so he changes a function to accept three arguments instead of 2. The last argument is the boolean flag that splits the argument with the If structure. This is where the code reviewer realizes that if the developer creates a new class for the new business logic model, the function remains straightforward. The decision-making problem is moved to the unique style.

The second solution: suggesting more effective ways to solve the problem

This approach appears in 2 different parts, suggesting more concise solutions (fewer lines of code) or a solution that performs faster. However, staying away from people obsessed with code optimization is better. If you let them, they will recode the entire project. The way we proposed to check the code becomes more apparent with the following examples:

Example 1: The developer implements a solution using a for-loop with an If structure. In this situation, the code reviewer suggests recoding this code with list comprehension and the If filter.

# First approach
available_employees = []

for an employee in employees:
If employee.is_working():
available_employees.append(employee)

return available_employees

# the Second approach, after the code review
, return [employee for an employee in employees if the employee.is_working()]
Copy

Second example: The developer uses the Constant List of values ​​to identify the variable inside it. In this situation, the code reviewer suggests using a tuple to optimize the search. Checker 2 also offers Benchmark List, Tuple, and Set to prove the right choice:

# original code
ALLOWED_STATUSES = [
‘NEW, ‘
‘WAITING_FOR_RESPONSE, ‘
‘OVERDUE, ‘
‘REOPENED, ‘
‘ESCALATED, ‘
]

def can_be_opened(ticket):
return ticket. status in ALLOWED_STATUSES

# benchmark using the time it module
## list
python3 -m time it -s ‘ALLOWED_STATUSES = [“NEW,” “WAITING_FOR_RESPONSE,” “OVERDUE,” “REOPENED,” “ESCALATED”]’ ‘” NON_EXISTING” in ALLOWED_STATUSES’
> 5000000 loops, best of 5: 61.5 sec per loop

## tuple
python3 -m time it -s ‘ALLOWED_STATUSES = (“NEW,” “WAITING_FOR_RESPONSE,” “OVERDUE,” “REOPENED,” “ESCALATED”)’ ‘” NON_EXISTING” in ALLOWED_STATUSES’
> 5000000 loops, best of 5: 56.1 sec per loop # Negligible improvement

## set
python3 -m time it -s ‘ALLOWED_STATUSES = {“NEW,” “WAITING_FOR_RESPONSE,” “OVERDUE,” “REOPENED,” “ESCALATED”}’ ‘”NON_EXISTING” in ALLOWED_STATUSES’
> 20000000 loops, best of 5: 15.6 sec per loop  # 4 times faster!
Copy

Finally, the developer may not even use Set. This process checks for five long items in a list that are not in a critical location.

Third solution: Clone the code locally for checking

This simple but efficient method shows the code change more comprehensively. Experience has shown that although Github, Bitbucket, and Gitlab provide developers with a convenient way to review code by highlighting changed lines, “local code clone” seems to work in some specific situations.

The fourth solution: paying attention to the acceptance criteria

Attention to the acceptance criteria is not a cursory review of the codes to recognize the ticket in its title. This means that you first read the ticket title, then if the acceptance criteria are acceptable in it, confirm these criteria one after the other. To clarify this solution, let’s give an example:

Example: A developer writes code to calculate the shipping price of an item. A ticket reviewer reads this code in Acceptance Criteria 4 and realizes there is a rule for free shipping on items worth more than $200. This is where the reviewer issues a request to make changes to the code.

This approach should be placed at the beginning of the code review process. We know many examples where engineers do coding from a technical point of view and do not pay attention to the main reasons for writing the code in the first stage.

The fifth solution: read the tests first.

The approach of studying the test version is considered the best choice for code review. In addition to writing code, this approach is also used for reading codes. A code reviewer is required at this stage. The code reviewer must explain all the acceptance criteria specified in the ticket. At this stage, special attention should be paid to accepting the requirements.

Sixth solution: pay special attention to the names

Senior developers should have more knowledge about naming. The more knowledge senior developers have in naming, the more precise and concise words they choose. For some time, experienced developers working on a project should monitor the naming to prevent synonymous naming and make the code easier to understand for other developers.

Example: A developer finds a synonym name for a variable. This name is synonymous with long. It has French roots and looks unconventional. This is where the code reviewer suggests the developer use shared project names.

The main task of the code reviewer

Many people in the software world believe that the main task of a code reviewer is to teach other developers. However, this definition is not very useful. The code reviewer must identify bugs in the shortest possible time.