Why I Always Suggest Reviewing and Fixing Your Code

The concept of self-review is something that almost all programmers learn. However, isn't the specific self-review method "rereading the code and correcting it whenever you notice an error"?

In re-reading and making corrections each time, you must go back and forth between "reading the source code and finding bugs" and "fixing the bugs."

This is equivalent to switching between two or more tasks frequently, which can lead to distractions and mistakes in both tasks.

Suppose you have another person and send him/her a review request for the pre-self-review code. Since you only concentrate on reading the source code and finding bugs, you will likely find more issues than if you read back and fix each time.

Conversely, wouldn't it be possible to improve self-review quality by making them more similar to regular reviews and separating "reviews" from "corrections"?

How to make self-review more like a regular review

In conclusion, recording the points pointed out during the self-review and the regular review is most important. In other words, the basics are to read the source code posted on the pull request and leave comments on the problematic lines.

It's simple, but the effect is enormous. The overhead of going back and forth between review and fix is gone, and the recorded issue becomes the following fix task list.

It also serves as evidence to other reviewers that "I did a self-review." Even if you don't have enough experience or skills to remove as many bugs as the reviewer wants, if you can get a glimpse of the issues pointed out and the process of solving them, you may be able to get more appropriate advice from the reviewer. The impression of the words that you did a self-review properly will be much better.

Aiming to reduce the cost of attention and improve quality

This section is exactly what I wanted to argue. Self-reviews have advantages over regular reviews that involve others. That's the reduction in care costs.

Typically, when reviewing someone else's code, we always have to deal with factors that are not directly related to the review, such as differences in thinking about coding, the mental state and position of the reviewer, and the time it takes to confirm corrections to the points pointed out.

I'm left and right, and I'm going to have a good time with a detailed point, and I'm going to spend time thinking about the pointed-out sentence that doesn't stand out. This is the cost of care. It is a very problematic practice when considering software quality first, but it cannot be ignored entirely when considering the compromise with reality.

However, in the case of self-review, unlike the review to others, the cost of attendance can be reduced to zero as much as possible because you are the other party. Don't hesitate to point out things you don't like roughly and concisely. "I don't like the naming of the function," "The variable name is a typo," "I want to divide the function because it is too long," "There are not enough tests when doing XXX," "I want supplementary comments," etc. I will point out my feelings.

What if you could reduce the cost of your attention and raise more issues than you would in a regular review? Once you get used to it, you may even feel a sense of pleasure in increasing the number of items to point out. Rather than being pointed out by others later, it is cheaper to point out and fix it yourself, both in terms of time and mental. That is the unique strength of self-review.

Take advantage of the convenient features of Pull Request

From here on, I will introduce useful functions for reviews provided in GitHub's Pull Request. It's not unique to self-reviews, so if you know it, you can skip it.

[Viewed] Put a check in the file that has been read

Viewedcheck the box to omit the display if you have finished reviewing the code. It's also valuable for automatically uncheck Viewed if a change is committed to an old file. Since the check is tied to the individual, you can use it from the usual review.

Resolve Conversation Use After Resolving Self-Review Issues

If you press to resolve the conversation on the PR, you can omit the display from the PR tree. However, Resolve Conversationthere is a high possibility that unresolved items will be left unsolved by mistake, so I feel that the team must think about the operation of "who pushes it and when."

In the case of self-reviews, it's a good idea to push each time you solve a problem actively. Only unresolved items are displayed in the tree, making it easier to grasp the progress of fixes. Resolve Conversation When sending a review request to others, all conversations should be completed.

Lastly

In this article, I used a code review using GitHub Pull Request, but the concept can also be applied at the design stage, such as basic design and requirement specifications. Even if it is not a pull request, if it has a comment function, it can be used as a review indication.