How to Code Review

Introduction

As a front-end engineer, you are often the team member who submits the most pull requests. To make your PRs easier to test and facilitate a smoother review process, I’ve summarized some key considerations.

Describing Your Pull Request

• Clearly state the purpose of this pull request. For example: fixing layout issues, adding a feature, styling a specific screen, etc.
• Remember that all team members can see the pull request, so ensure that your description provides sufficient information.
• Clearly indicate what kind of feedback you are seeking.
• Use prefixes to denote the status of your pull request.
• Add team members who need to review this code (you can use GitHub’s assign feature).

Providing Feedback

• If you disagree with something in the pull request, take a moment to reflect on why you feel that way. Once you’ve articulated your thoughts, leave a comment.
• Use questions instead of commands. For example, “Why didn’t you use this approach?” is better than “Don’t write it this way!” Start by asking for their thoughts or reasoning; they might have valid reasons for their choices, which can lead to productive dialogue.
• Explain why you believe certain code should be modified (e.g., it doesn’t adhere to the style guide, it doesn’t follow naming conventions, it lacks test cases).
• Suggest better methods to improve the current code.
• Avoid comments that can come off as aggressive (e.g., “This is written stupidly.”).
• Stay humble.
• Avoid making definitive statements (e.g., “Don’t write code this way!”).
• Online communication can sometimes lead to misunderstandings. In such cases, consider discussing things face-to-face.
• Use an emoji to enhance your tone, for example: good job 👋 👍. Needs correction 👻 (this might seem a bit sarcastic).

Responding to Feedback

• Thank those who are willing to help you with code reviews.
• If there are any unclear points, don’t hesitate to ask questions.
• If the feedback has been addressed or is included in a specific commit, provide a link to it.
• If discussions become increasingly complex and lack resolution, try to communicate face-to-face.

Everyone

• Everyone must recognize that different coding styles exist, and there are always multiple solutions and options when programming. Therefore, during discussions, it’s essential to weigh the pros and cons and thoroughly explain why you believe your approach is better.
• Ask questions instead of issuing commands.
• Avoid assigning blame (e.g., “That’s your code, not my problem” or “This part is your responsibility”).
• Try to understand the author’s perspective and thoughts.

Conclusion

While I’ve summarized many points above, the core theme revolves around considering the other person’s perspective. Think about what kind of pull request you would like to see, and approaching it from that angle may resonate more with you. After all, if mistakes happen—especially due to oversight that leads to deploying code to production—you’ll end up wasting the entire team’s time fixing bugs and redeploying.