Review code, listening is quite dreadful, but it is not easy, and only when directly embarking on it, do you understand to read the code of others, to comment or refactor it, not simple, And sometimes, commenting so that they are happy is also an art.
First, let’s start by answering the question: “Why do we need to review the code?”
- Help reduce the number of bugs in code
- Ensure all requests have been made
- An effective way to learn from each other and get familiar with code base.
- Help maintain a common style code for the whole team (as in rails or use rubocop)
- Mount teams – encourage developers to talk to each other to find the best solution
However, review code is often one of the most difficult and time-consuming parts of the development process.
After the code has been completed, people may have to wait many days until the code has been reviewed. Then when you start the comment process again, fix comment between the reviewer and the person who is re-recorded, sometimes costs you weeks. You are stuck between new features and old features that need to be fixed.
That’s why it’s important to build a detailed process of team code review.
In general, you will have to have detailed instructions for both sides, before creating a pull request and while reviewing. Detail:
Define the conditions for creating a pull request:
The following are essential for minimizing conflict:
- Make sure that code build is successful.
- Read and annotate the code.
- Build and run the test.
- All code in the codebase section needs to be tested.
- Lick ticket / issue into the pull request.
- Do not transfer to reviewer when the above conditions are not met.
Responsibilities of reviewers
Although the reviewer is the last person who has the right to merge the pull request, the following instructions for the reviewer will have less risk in the long run:
1. Communicate with the reviewer – give your reviewer a task request. Since most of us were in the reviewer position, put yourself in the reviewer’s position and wonder, “Is this enough for us?”
2. Create small pull requests – Creating small pull requests is the best way to speed up review. Keeping pull requests is small enough that you can perform a review loop – fix comments quickly and accurately. In general, small code changes are easier to test and reviewers can understand the structure and logic more.
3. Avoid changes while reviewing the code – Major changes in the review process will basically make the review process review from the beginning. If you need to make major changes after submitting the review, you may need to include the existing review and additional changes. If you want to make major changes after starting the code review process, be sure to talk to the reviewer about this issue as soon as possible.
4. Respond to all reviewer’s comments – Even if you don’t make their comments, respond and explain why. If there’s something you don’t understand, ask questions.
5. Review code is discussion, not dictation – you can think of most comments as a proposal rather than a requirement. Not agreeing with the reviewer’s comment is not a problem, but you need to explain the reason and give them a chance to respond.
The responsibility of the reviewer
Because the reviewer is the last person to merge the code, their most important responsibility is to minimize errors. The reviewer should:
- Note the description and requirements of the task.
- Be sure to fully understand the code.
- Divide your comments into 3 categories: Mandatory, optional and positive. The first is the comments that programmers need to accept to change, and finally comments to the developer because of the good code.
- Avoid commenting too many times with the same content
Instead of writing
If you comment a lot, you can use Github review instead, and notify the developer when you’re done.
5, Know when to have a live discussion: After a series of reciprocal comments without results, send a live discussion request, talk directly to help solve the prize. solution to solve problems faster and easier.
Finally, some of the questions below will be a great tool to help you improve your review process:
- Do I have difficulty understanding this code?
- Is there something too complicated to refactor?
- Is this code streamlined in the directory structure?
- Is the class name intuitive and correct for functionality?
- Is any class too big?
- Is there any method too long?
- Are method names clear and intuitive?
- Did you write enough documents for the code sections you need (like writing docs for APIs)?
- Has the code been tested carefully?
- Is there any way to make code more efficient?
- Is the code true to the team’s standards?
There are many different and effective habits based on the needs of the team. So this is just a personal opinion and there may be other ways that are more effective for your team. Hopefully the article can help you or your team somewhat to build an effective review process.
Source: https://medium.com/free-code-camp/code-review-the-ultimate-guide-aa45c358bbf5