コードレビュー方法

前言

フロントエンドエンジニアとして、通常チーム内で最も頻繁にプルリクエストを送信する人になります。自分のPRがよりテストしやすく、レビュアーがレビューしやすくなるように、いくつかの注意事項をまとめました。

プルリクエストの説明

• このプルリクエストの目的。例えば：レイアウトの修正、新機能の追加、特定の画面のスタイルなど
• 各企業のメンバーがプルリクエストを見れることを忘れず、プルリクエストの説明が十分な情報を提供していることを確認してください。
• どのようなフィードバックを求めているのかを明確に述べる。
• プルリクエストの状態を示すためにプレフィックスを使用する。
• このコードを確認する必要があるメンバーを追加する（GitHubのアサイン機能を使用できます）

フィードバックを提供する

• プルリクエスト内の書き方に同意しない場合は、一度立ち止まり、なぜ同意しないのか考えてみてください。考えがまとまったらコメントを残す。
• 命令の代わりに質問を使う。「なぜこの書き方を採用しないのですか？」は「そう書かないで！」よりも優れています。相手の考えや意見を尋ねてみることで、彼らがそのように書かなかった理由があるかもしれません。この場合、適切なコミュニケーションを図ることができます。
• なぜこれらのコードを修正する必要があると考えるのかを説明する（スタイルガイドに合っていない？会社の命名規則に従っていない？テストケースが書かれていない？）
• 現在のコードを改善するためのより良い方法を提供する。
• 攻撃的なコメントをできるだけ避ける。（例：そんな書き方は馬鹿げている。）
• 謙虚さを保つ。
• 断定的な表現を避ける。（そんな風にコードを書かないで！）
• オンラインでのコミュニケーションでは、誤解が生じることが避けられません。この場合、対面でのコミュニケーションを考慮することができます。
• あなたの意見を強調するために、絵文字を使う。例えば：good job 👋 👍。 修正が必要ですよ👻（これはちょっと皮肉っぽいですか？）

フィードバックに返答する

• コードレビューを手伝ってくれる人に感謝する。
• 不明な点があれば、質問することが大切です。
• このフィードバックが実装されたり、特定のコミットに含まれている場合は、そのリンクを提供する。
• 議論がますます複雑になり、結論が得られない場合は、対面でのコミュニケーションを試みる。

みんなのこと

• 皆が異なるコーディングスタイルを持っていることを理解する必要があります。また、プログラミングには多くの解決策や選択肢があるため、議論の際は適切にバランスを取り、なぜそれが良いと思うのかを十分に説明するべきです。
• 質問する形で進め、命令形は避ける。
• 責任を区分しない（これはあなたの書いたものだから私には関係ない、これはあなたが処理する部分です）
• 著者の視点や考えを理解しようとする。

結論

以上の点をまとめましたが、最も重要なのは相手のことを考えることです。どのようなプルリクエストを見たいか、この視点から考えることで、より深く感じることができるかもしれません。 結局のところ、もしミスを犯したり、自分の不注意でコードを本番環境にデプロイしてしまった場合、チーム全体の時間を無駄にしてバグを再度見つけ、再デプロイする必要があるのですから。