It’s not recently that I have been assigned a new job at the project, which is to review and merge code for everyone in the team, a job that is usually only for the leader or a senior … sounds pretty dread =)) but It’s not easy at all, and it is only when you start to do it directly that you understand to read and understand other people’s code, to comment or refactor it, it is not simple, and sometimes, commenting for them Fun fixing is also an art. In this article I will share some experience during my reviewer time.
Building processes and conditions for the team before to review
Review code is often one of the most difficult and time-consuming parts of a development process.
After coding, people may have to wait several days until the code is reviewed. Then after starting the comment process again, fix the comment between the reviewer and the reivew, sometimes your weekly consumption. You are stuck between new features and old features that need fixing.
That is why the construction of a detailed process to avoid losing time on both sides, below are a few dev brothers we need to do before to review.
- Make sure that the code runs logically according to the spec (the views of dev and QA must be the same).
- Code must be fully annotated.
- Run unit tests (if available) and make sure the code runs with the old data (in case of maintaining code or making change requests).
- Search and re-test carefully the code you have used to fix it elsewhere (code base, common)
- For pull migrations that need to run without errors and rollback successfully, write sql update for old data if needed
- Compliance with code standards in the project (coding convention)
- Choose some test cases of QA to test if any
- Caption full information on pull requests such as ticket, why fix, how to fix the screen, …
- Check the list of files changed, added, deleted … to see if the content you want to push or not, if completed above, will send notifications to everyone to review.
The responsibility of the reviewer
- Put yourself in the shoes of a reviewer: ask yourself, “Is this code good enough, is it optimized, or is it just workable?”
- Create small pull requests: Small pull requests are the best way to speed up review. Keep the pull requests small enough so that you can make the review – fix comment quickly and accurately. In general, small code changes are easier to test and reviewers can understand the structure and logic.
- Avoid depositing: depositing unrelated code into the pull ticket will make the reviewer difficult to read the logic.
- Avoid changes during review code: big changes in the review code process will essentially cause the review process to review from the beginning. If you need to make major changes after submitting your review, you may need to include the existing review and additional changes. If you want to make big changes after starting the review code, make sure to talk to the reviewer about this as soon as possible.
- Respond to all reviewer comments: even if you don’t follow their comments, please respond and explain why. If there is something you do not understand, ask questions.
- Review code is discussions, not misleading – you can think of most comments as a proposal rather than a request. It doesn’t matter if you disagree with the reviewer’s comment, but you need to explain the reason and give them a chance to respond.
Reviewer
- Understand your teammates: Understand the people who take the time to write the code you will review. They also want the code to be complete. Your colleagues have done their best and no one wants to give bad code.
- Each Pull Request has a problem in communication. Try to understand and sympathize with your teammates and improve the code together. Instead of saying
Bạn viết hàm này khó hiểu quáplease useHàm này làm cho tôi hơi khó hiểu một chút. Liệu chúng ta có thể tìm được một tên biến phù hợp hơn được không ? - Read the request in the ticket, make sure you understand the code
- Divide comments into 3 categories: Mandatory, optional and positive, attach link document framework if you want the author to better understand the effects of the code
- Avoid commenting with the same content: instead of repeating cmt with an error on multiple lines, you only need to place one comment and note the other similar parts
Tips to increase productivity review
Search files quickly in Repository
This is one of the shortcuts that I find best and most convenient on Github. It can help us find any file in Repository 1 quickly.
First you open a certain Repository. Then press the “t” key and it will go to the search screen. In this screen, you just need to enter the file name you want to search.
Suggest change the code in Pull Request
When we comment on a piece of code in Pull Request. We can suggest replacing the code by using the “Suggested Changes” feature. Pull Request creators can apply directly to your code changes without having to move Github.
To create a proposal, just surround your code with a Markdown tag, with a suggestion tag.
Now the Pull Request creator can change the file directly on Github without necessarily having to change it manually.
Display Github as in IDE
For those who are familiar with the IDE, it organizes folders in the sidebar tree.
On Github can do the same, but you need to install an extension on Chrome called Octotree extension
Jump to function while reviewing code
Anyone who has ever reviewed code before knows it, when reviewing a piece of code. It is absolutely inevitable to see functions related to that code.
Normally, people will open a new tab in the browser and see the function they want to see. This way is okay but quite time consuming. There is a faster way for you to see the related function by pressing the “t” key. When that will show 1 dropdown and select the function you want to see is.
Create permalink for 1 file
The content or link to a file in Github may be changed. For example, today use this file. But tomorrow the file may not be available and will be deleted. So how can share the path of a file to others without fear that the path will be changed.
In Github can help you do this a very simple way. First open that file on Github.
For example, my file has the following path:
https://github.com/nooptr/docker-rails-mysql/blob/master/Dockerfile
Then you press the “y” key it will automatically turn the path into a path like this:
And this is the static path and not changed. Even if your other file has been deleted.
In fact, this is because the 34bd44a48b0b66519fcbdfa2165d115a379db84a is the commit code of the file at that time. So if you delete the file, the old commit remains so it should still be viewable.
View the history of changes to a file
If you want to see the change history of a file on Github you can do so by pressing “b”. It will then show who changed which line in the file at what time. This is no different from git blame. But looking at the interface I find it much easier to see.
Powerful code search
Github indexes most code and provides a powerful search function on it. If you want to search for a certain text on Github, just press the “/” button and enter the word you want to search.
Reuse the saved reply
If you want to comment with comments a few days earlier to save time, there’s no need to type. Github then gives you the ability to save previous comments by creating 1 saved replies. Next time you want to reuse the previous comment, you just have to choose from the dropdown.
