コードレビューの進め方

はじめに

フロントエンドエンジニアは、通常チーム全体の中で最もプルリクエスト（PR）を出すことが多い存在になりがちだ。自分のPRがよりテストされやすく、レビュアーにとってもレビューしやすくなるよう、いくつかの注意点をまとめてみた。

プルリクエストの説明

• このプルリクエストの目的。例えば：レイアウトの修正、新機能の追加、特定画面のスタイル調整など
• 社内のメンバー全員がプルリクエストを見られることを意識し、十分な情報を提供できるように記述すること。
• どのようなフィードバックを求めているかを明確に説明すること。
• プレフィックス（prefix）を使って、プルリクエストの状態を明示すること。
• このコードを確認する必要があるメンバーを追加すること（GitHubのアサイン機能などを活用する）。

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

• プルリクエスト内の書き方に同意できない場合は、まず立ち止まって、なぜ同意できないのかを考えてみよう。考えがまとまってからコメントを残すこと。
• 命令ではなく質問の形をとること。「どうしてこの書き方を採用しなかったのか？」は「こう書くな！」よりも優れている。まずは相手の考えや意見を聞いてみよう。そう書かなかった理由があるかもしれず、そこから適切なコミュニケーションや意見交換ができる。
• なぜそのコードを修正すべきだと考えるのかを説明すること（スタイルガイドに沿っていない？会社の命名規則に合っていない？テストケースが書かれていない？など）。
• 現在のコードを改善するための、より良い方法を提案すること。
• 攻撃的なコメントは極力避けること。（例：「こんな書き方バカげている」など）
• 謙虚さを保つこと。
• 決めつけや断定は極力避けること。（「こんなコードを書くな！」など）
• オンラインでのやり取りでは、どうしても誤解が生じやすい。そういうときは対面でのコミュニケーションを検討してみよう。
• 絵文字を使ってニュアンスを和らげたり強調したりすること。例えば：good job 👋 👍。修正が必要だよ👻（これはちょっと煽りっぽいかも？）。

フィードバックへの対応

• コードレビューをしてくれた人に感謝すること。
• よく分からない点があれば、遠慮なく質問すること。
• フィードバックを反映した場合や特定のコミットに対応が含まれる場合は、そのリンクを共有すること。
• 議論が複雑化して結論が出ない場合は、直接対面で話し合ってみること。

全員が意識すべきこと

• 人それぞれコーディングスタイルが異なること、そしてプログラミングには常に多くの解決策や選択肢があることを理解しなければならない。そのため、議論する際は適切にトレードオフを検討し、なぜその方が良いと考えるのかを十分に説明すべきだ。
• 命令するのではなく、質問すること。
• 責任を押し付け合わないこと（「これは君が書いたんだから僕には関係ない」「ここは君が処理すべき部分だ」など）。
• 作成者の視点や考え方を理解しようと努めること。

結論

ここまで多くのポイントをまとめたが、根底にあるのは相手への思いやりがあるかどうかだと僕は思う。自分ならどんなプルリクエストを見たいか、という視点に立ってみると、より実感しやすいかもしれない。 何と言っても、もしミスがあり、自分の不注意で本番環境（production）にコードがデプロイされてしまえば、チーム全体の時間を無駄にしてバグを再調査し、再デプロイする羽目になってしまうのだから。