Code Review.

I made this in canva

Hi,
some of us, maybe hate the review process, hate the feedback, hate the criticism, hate something to show our weakness, to show our mistake/s, right? but actually, we learn something from that.
a lot of quotes about mistakes that I found on google but I choose this one.

A person who never make a mistake never tried anything new. — Albert Einstein

So it’s okay with the mistakes, take it easy, don’t overthink.
Same as the code review in the company, we can get a lot of improvement from the reviewer (vice versa). so we don’t need to hate this process.

Let’s start with making a pull request, so your colleagues can review your code.

As we know, we made a Pull Request to enhance the current code and to add something new to the current code repo. Which means the code review is a good thing right?
and how to make it the good thing have a good value and will give an improvement?
okay, let’s start with creating Pull Request

How To Make A Great Pull Request 👍

first, you need to read the card issue first and make sure the changes make sense, and if not make sense you can give feedback to the author (who creates the card issue) and give the reasons too

second, keep the changes less. Don’t make a lot of changes into a single PR to make it easier to solve, that’s kind of lazy. You have to be creative and make the changes less so will cut the duration of the review processes.

third, do self-review. Re-read the code and ask yourself “is this necessary?” “Does the name match?” if not feel free to remove it it’s yours. don’t forget to remove the noise such as the unnecessary comment or unnecessary print.

forth, create meaningful titles, Often the title is generated from the branch name. you can use the issue title as your PR title and don’t forget to begin with the issue number.

fifth, write complete descriptions.
to make the review process shorter, we need to add a complete description in your Pull Request.

 — Put the purpose of your PR, such as the fixing, or enhancement, or add.
 — Attach the link of issue or something
 — Write down the implementation description. 
 — Add “how the reviewer reviews your PR”.
 — Add additional information, like requirements of libraries.

That’s all the description that we need to attach to your PR. (or maybe you have another important piece of information, you can attach it)

sixth, don’t merge it until all your colleagues/the best reviewer approve it. Speaking of manners, it’s good manners to wait until everyone who has made a suggestion has had a chance to hear your response and evaluate it. but if your team has a lot of members you can define who is the best reviewer (master) and how much the reviewer contributes to your PR.

The best reviewer is the person who will be able to give you the most thorough and correct review for the piece of code you are writing. This usually means the owner(s) of the code, who may or may not be the people in the OWNERS file. Sometimes this means asking different people to review different parts of the CL. here the source

How To Treat the Pull Request of your Team

don’t forget to read the issue card first before starting the review

First.
Treat the review as your main task, since the review process is the task of the team, not an individual task.

Second.
Don’t leave the comment without any solution, such as “remove this”, but you don’t tell the reason behind that. explain your suggestion, because you will not only improve the code but improve the person.

“if you give the people the fish, you just feed him at that time, but if you teach him how to fishing you can can feed him all the tim”

Third.
Don’t be rude when you do the review code, instead of you commenting “this unnecessary line” it will be better if you comment like this “hey August, I think we should remove this condition since there are no anything goes through to this condition”

Forth.
Allocate your time, the review process maybe take your time a lot to make sure the code has a good quality and standard.
as my experience, I allocate my time in the morning before starting work to comment or review the Pull Request

Fifth.
Ask, don’t make assumptions. when you found something strange in your colleague's code, just ask don’t assume. the example, your colleague suddenly adds a new library without telling you, or not attached in the document, and you don’t know the purpose of that, Just Ask! Maybe your collage have the reasons for that

Sixth.
Reach your colleague at the right time, maybe we have some several conditions, such as the Pull Request is a hotfix, need to be done as soon as possible, you can just reach them by DM. another condition, don’t talk about the code review in public or maybe not in the working hour.

Seventh.
Compliment your colleague code, code review is not to list your colleague mistakes, but if you found the good thing, good decision, or good implementation code, Let’s Appreciate your Colleague!

That’s all my experience how we do the review code in the team, you can take the good thing from it, and you can leave the bad things from it.

Thank you, please give me the feedback to improve my article.
Have a nice day, and stay health.

Reference: 
https://github.com/google/eng-practices