Preface

As a front-end engineer, I am usually the person who sends the most pull requests within the team. To make my PRs easier to test and review, I have summarized some points to keep in mind.

Description of the pull request

• State the purpose of this pull request, such as fixing layout, adding a feature, or styling a specific page.
• Remember that all members of the company can see the pull request, so make sure the description provides sufficient information.
• Clearly explain the type of feedback you are looking for.
• Use prefixes to indicate the status of your pull request.
• Add members who need to review the code (you can use GitHub's assign feature).

Providing feedback

• If you disagree with the approach used in the pull request, pause and think about why you disagree. Leave a comment only after you have thought it through.
• Use questions instead of commands. "Why didn't you use this approach?" is better than "Don't write it this way!" Ask for their thoughts or opinions first, as they may have valid reasons for their approach. This allows for appropriate communication and discussion.
• Explain why you think the code needs to be modified (e.g., does it not adhere to the style guide? Does it not follow the company's naming conventions? Is there a lack of test cases?)
• Provide better alternatives to improve the current code.
• Avoid making offensive comments. (e.g., This is a stupid way to write it.)
• Stay humble.
• Try to avoid making definitive statements. (Don't write code like this!)
• Misunderstandings can occur during online communication. In such cases, consider having face-to-face discussions.
• Use emojis to enhance your tone, for example: good job 👋 👍. Needs improvement 👻 (though this might be slightly sarcastic).

Responding to feedback

• Thank those who are willing to help with your code review.
• Ask questions about anything that is unclear.
• If the feedback has been implemented or is in a specific commit, provide a link to it.
• If the discussion becomes increasingly complex and no conclusion is reached, try to communicate in person.

Everyone

• It is important to understand that everyone has different coding styles, and there are often multiple solutions and choices when writing code. Therefore, during discussions, it is important to balance and fully explain why you think a certain approach is better.
• Ask questions instead of giving commands.
• Avoid assigning blame (e.g., "This is not my responsibility because you wrote it," or "This is your problem to handle.")
• Try to understand the author's perspective and thoughts.

Conclusion

Although the above points summarize many aspects, I believe the key focus is still on considering the other person's perspective. By approaching pull requests from this angle, you may gain more insight and understanding. After all, if an error occurs, even due to one's own negligence, and the code is deployed to production, it will waste the entire team's time to find the bug and redeploy it.