GitHubスタッフエンジニアに学ぶ効果的なコードレビューの方法について
はじめに
最近聞いたToday I LearnedのPodcastでGitHubのスタッフエンジニアによる効率的なレビューについての内容が面白かったので、元の記事を読んだところ、本として出版されててもおかしくないくらいに示唆に富む内容だったため、まとめてみた次第です。
↓元記事
記事の日本語訳は下のほうにまとめていますので、日本語訳を読みたい方はこちらを参照してください。
なお、このToday I LearnedというPodcastはアメリカで働くITエンジニアsのPodcastで、GAFAに勤務している方の話だったり、日本とは違うアメリカのテック業界の話とかもあったりして、とてもおもしろいので、ご興味ある方はぜひ聞いてみてください。
著者について
Sarah Vesselsさんという方でGitHubでスタッフエンジニアをしています。 過去8年間で7000以上ものプルリクエストをレビューしているということで、めちゃくちゃレビューの知見がつまっていました。
以下気になったところの要点をまとめていきます。
コードレビューとは
- 自分の作業を一時中断してでも、レビューをすることが多い。というのも、プルリクエストの状態というのは、すでにCIを通過しており、自分の進行中の作業よりもリリースに近い状態であり、自分のコードを完成させるよりも、レビューするコードを完成させるほうがいいと考えている。
→自分もコードレビューはなるべく早いほうがいいと思っているのですが、この観点を意識することは多くなかったので、指摘されて目からウロコでした。
なぜコードレビューをするのか
- プルリクエストを会話の始まりとみなしている。そして、レビュアーから多くのことを学んできた。逆に自分のレビューコメントもチームメイトのスキル向上に貢献している。つまり、コードレビューは影響力があり、昇進するためにはその影響を示す必要がある。→いいレビューやいいコードというのは、エンジニアとしてのキャリアにも影響する、と彼女は言っています。ただ、日本においてはスタッフエンジニアというキャリアはそこまで一般化していないので、これがそのまま日本のITエンジニアすべてにあてはまるかというと、そうでもないかと思いますが、エンジニアとしてのスキル向上としては、間違いなくプラスの影響があると思います。
良いコードレビューと悪いコードレビュー
-
レビュー担当者はコミニケーションの明確さが鍵。コメントの中で個人的な好みと、承認のためのものを明確に区別する必要がある。提案するアプローチ例があり、それが同じリポジトリ内からだと、実装の一貫性も保てるので、なお良い
-
逆に悪いコードレビューは明確さがないこと。コメントのない全体的な承認や拒否はプルリクエストの著者にレビューが十分に行われたかを疑わせることになる。
-
また、実装タイミングが不明確なコードレビューも著者にとっては不快となることがある。リファクタリングや追加のケースに対応することを提案すること自体は問題ではないが、それが前提条件となるかを明らかにすることが大事。プルリクエストがそのままでも承認可能であれば、そう述べるべき。
→リファクタリングに関しては自分はちょっと否定的です。リファクタリングは後回しにされることが多く、何時間もかかるものでなければそのプルリクエストで修正したほうが良いと思います。ただリファクタリングも個人の好みになる場合があります。なので最近は"nuts"(取るに足らないもの)は修正するかどうかは任せます、という感じにしてます。
提案
- プルリクエストの著者としては、質問を受け取ることに感謝しています。質問を受けることで、なぜその変更に自信を持っているのかを説明する機会が生まれ、必要に応じて問題やクエリ、グラフを引用できます。また、これによって他のレビュアーや、過去の決定の背景を追いかけている将来の読者と知識を共有することができます。
肯定的なコメントを残す
-
質問をするだけでなく、プルリクエスト内で同意する部分にもコメントを残すのが良い習慣です。これらのコメントは、あなたが変更を読み、理解したことを強調したり、コード内の何らかの仮定を確認したりするために役立ちます。いくつかの例を挙げます：
• 「他のクラスで使用されているパターンに一致しているようです。」
• 「このためのテストを追加してくれてありがとう！」
• 「以前よりもはるかに可読性が向上しています。」
私の経験では、このようなコメントを受け取るのは単純に気持ちの良いものです。コードレビューを受けるのは時に疲れることがありますが、多くの質問や提案を受けている中で、何も要求されず、すでに行った作業を支持し認めてくれるコメントがあると、ちょっとした心の励みになります。
→今回の記事で一番印象深かったところです。自分もPodcastで肯定的なコメントについて聞いたときにハッとさせられました。LGTMは使うのですが、なんか機械的だし具体的な点を褒めたほうが著者としてはとても自信になります。なので、積極的に褒めていこうと思いました。
## コードレビューを最大限に活用する方法
自分のコードをレビューする
GitHubのシニアソフトウェアエンジニアであるPaul Smithから学んだのは、他人にレビューを依頼する前に自分のプルリクエストをレビューするということです。そして、私はこれを強くお勧めします。まず最初に自分で確認し、非自明な変更や、他人のプルリクエストで見た場合に自分が質問するような箇所にコメントを残しておくと良いです。セルフレビューは、プルリクエストが大きすぎるかどうかを判断し、分割した方が良いかどうかを見極めるのにも役立ちます。
→これは自分もやっていて、なぜか他人のレビューするときは、なんでこんな些細なミスを・・・と思ったりしていたのですが、自分も同じようなレビューがあったりします。なので、プルリクエストを出したい気持ちを抑えて、一呼吸つけて自分でもレビューするようにリクエスト前にコードを一読しています。
ドラフトプルリクエストを活用する
新しいプルリクエストを作成するとき、プルリクエストをドラフトとして設定するオプションがあります。私はレビューを求めるかどうかを示すためにドラフト段階を多用しています。例えば、必要なCIビルドが失敗していたり、まだ作業が完了していない場合、ドラフトのままにしておきます。私は他の人のプルリクエストにも同じことを期待しています：もしそれがドラフトなら、著者はレビューを求めていないと仮定します。レビュー準備が整っている場合は、十分な承認を得ることが唯一のリリースに向けたステップだと考えます。
→自分も結構ドラフトを活用します。それは、プルリクエストのなかで何をやったか、レビュアーにどの点を注意してみてほしいかなどの詳細を書くために一旦整理したいからです。その間レビュワーが無駄にレビューをしない状態だと明記するためです。
以上となります。
ChatGPT-4oを用いて日本語に翻訳した内容はこちらになります。
コードレビューのプロセスを細かく調整する
レビューするプルリクエストを見つける方法
私は自分のGitHub通知インボックスを常に確認しています。これは、ブラウザに固定している数少ないタブの一つで、いつでも利用できるようにしています。CIの結果を待っている間や、タスクの間、仕事を始めるとき、または少し時間が空いたときなど、私はインボックスをチェックするのが好きです。ほとんどのプルリクエストはここで見つけています。GitHubのチームでは、特定のSlackチャンネルを拠点として使用することが多く、レビュー準備が整ったプルリクエストをそこで共有することが、プルリクエストを発見するもう一つの主要な方法です。
また、GitHubのSlackインテグレーションを使用して、自分のチームに関連する新しいプルリクエストをSlackチャンネルに購読するように設定することでも良い結果を得ています。Slackに表示されるプルリクエストをフィルタリングするために、チームに固有のラベルを使用し、Slack内で/github subscribe your/repo pulls +label:"your-team-label"のようなsubscribeコマンドを使います。
提案
クエリ内でteam-review-requested:修飾子を繰り返して、さまざまなコードオーナーからのレビューリクエストを集めることができます。
私は次のようなクエリを使って、レビューが必要な未処理のプルリクエストを検索するのが好きです：is:open archived:false is:pr org:github -is:draft team-review-requested:github/relevant-codeowner-team。このクエリでは、GitHub組織内の、ドラフトではなく、該当するコードオーナーチームがレビューを要求している未アーカイブのオープンなプルリクエストが見つかります。私は通常、review:required修飾子を省略します。というのも、他のチームメイトがすでにレビューしているプルリクエストでもレビューすることに興味があるからです。結局のところ、コードのレビューは著者だけでなく、私が責任を持っているコードに影響を与える変更について最新情報を把握するのにも役立つからです。
レビューチームを使って通知を管理する
コードの変更があまりにも大きなチームに通知されると、誰もがその変更のレビューを自分の責任だと思わず、レビューされずに放置されたり、重要なレビュアーが通知を見逃してプルリクエストがマージされてしまったりする可能性があります。これらのシナリオは、製品の品質に影響を与えます。
通知を管理可能に保つために、可能であれば、自分が所属するコードオーナーチームの数を絞ることをお勧めします。そうすれば、インボックスに届くプルリクエストがノイズではなく、実際にレビューすべきものとして感じられます。大規模な包括的なコードオーナーチームはフォールバックオプションとしては悪くありませんが、自動レビューリクエストの最初の選択肢としては最適ではありません。リポジトリのCODEOWNERSファイルを整理して、明確に定義されたコード境界を設けることで、通知を制限し、レビュー担当者が通知疲れを避けられるようにします。
また、チームベースの通知を制限するもう一つの方法は、ファーストレスポンダーチームを作成し、スケジュールに基づいてチームメンバーを自動的に追加・削除することです。これにより、チームは日常のコードベースに集中し、スケジュールされたファーストレスポンダーがチームのサービス領域に関連するプルリクエストの通知を受けることができます。例えば、PagerDuty APIを使って、特定の日のファーストレスポンダーを決定し、Octokitライブラリを使ってチームメンバーを追加・削除することができます。
チーム間でコードレビューを標準化するための自動化
リポジトリレベルの設定と自動化（例：CODEOWNERSファイルやブランチ保護ルールを使用すること）は、チーム間でレビューのプロセス基準を強制するのに役立ちます。プルリクエストでコメントする価値がある内容など、他の基準は私たち人間が維持しなければなりません。チーム内でコードレビューがどのように機能するかを文書化し、コードレビューを提供する人やプルリクエストを提出する人が、自分のプルリクエストがどのようにレビューされるか、レビューの期待されるターンアラウンドタイム、およびレビューを促進するために使用される自動化について理解できるようにしましょう。
コードレビューのプロセスを細かく調整する
レビューするプルリクエストを見つける方法
私は自分のGitHub通知インボックスを常に確認しています。これは、ブラウザに固定している数少ないタブの一つで、いつでも利用できるようにしています。CIの結果を待っている間や、タスクの間、仕事を始めるとき、または少し時間が空いたときなど、私はインボックスをチェックするのが好きです。ほとんどのプルリクエストはここで見つけています。GitHubのチームでは、特定のSlackチャンネルを拠点として使用することが多く、レビュー準備が整ったプルリクエストをそこで共有することが、プルリクエストを発見するもう一つの主要な方法です。
また、GitHubのSlackインテグレーションを使用して、自分のチームに関連する新しいプルリクエストをSlackチャンネルに購読するように設定することでも良い結果を得ています。Slackに表示されるプルリクエストをフィルタリングするために、チームに固有のラベルを使用し、Slack内で/github subscribe your/repo pulls +label:"your-team-label"のようなsubscribeコマンドを使います。
提案
クエリ内でteam-review-requested:修飾子を繰り返して、さまざまなコードオーナーからのレビューリクエストを集めることができます。
私は次のようなクエリを使って、レビューが必要な未処理のプルリクエストを検索するのが好きです：is:open archived:false is:pr org:github -is:draft team-review-requested:github/relevant-codeowner-team。このクエリでは、GitHub組織内の、ドラフトではなく、該当するコードオーナーチームがレビューを要求している未アーカイブのオープンなプルリクエストが見つかります。私は通常、review:required修飾子を省略します。というのも、他のチームメイトがすでにレビューしているプルリクエストでもレビューすることに興味があるからです。結局のところ、コードのレビューは著者だけでなく、私が責任を持っているコードに影響を与える変更について最新情報を把握するのにも役立つからです。
レビューチームを使って通知を管理する
コードの変更があまりにも大きなチームに通知されると、誰もがその変更のレビューを自分の責任だと思わず、レビューされずに放置されたり、重要なレビュアーが通知を見逃してプルリクエストがマージされてしまったりする可能性があります。これらのシナリオは、製品の品質に影響を与えます。
通知を管理可能に保つために、可能であれば、自分が所属するコードオーナーチームの数を絞ることをお勧めします。そうすれば、インボックスに届くプルリクエストがノイズではなく、実際にレビューすべきものとして感じられます。大規模な包括的なコードオーナーチームはフォールバックオプションとしては悪くありませんが、自動レビューリクエストの最初の選択肢としては最適ではありません。リポジトリのCODEOWNERSファイルを整理して、明確に定義されたコード境界を設けることで、通知を制限し、レビュー担当者が通知疲れを避けられるようにします。
また、チームベースの通知を制限するもう一つの方法は、ファーストレスポンダーチームを作成し、スケジュールに基づいてチームメンバーを自動的に追加・削除することです。これにより、チームは日常のコードベースに集中し、スケジュールされたファーストレスポンダーがチームのサービス領域に関連するプルリクエストの通知を受けることができます。例えば、PagerDuty APIを使って、特定の日のファーストレスポンダーを決定し、Octokitライブラリを使ってチームメンバーを追加・削除することができます。
チーム間でコードレビューを標準化するための自動化
リポジトリレベルの設定と自動化（例：CODEOWNERSファイルやブランチ保護ルールを使用すること）は、チーム間でレビューのプロセス基準を強制するのに役立ちます。プルリクエストでコメントする価値がある内容など、他の基準は私たち人間が維持しなければなりません。チーム内でコードレビューがどのように機能するかを文書化し、コードレビューを提供する人やプルリクエストを提出する人が、自分のプルリクエストがどのようにレビューされるか、レビューの期待されるターンアラウンドタイム、およびレビューを促進するために使用される自動化について理解できるようにしましょう。
いくつかのチームでは、レビュー対象のプルリクエストを追跡するためにプロジェクトボードを使用しています。私は、共有APIを管理しているチームが、他のチームメンバーによって頻繁に変更される領域を担当している場合、この方法がうまく機能しているのを見たことがあります。また、GitHubの通知だけに依存しているチームもあり、コードオーナーシップが明確に定義されていて、プルリクエストが届いたら即座にレビューすることを徹底している場合、この方法も有効に機能しているのを見たことがあります。
特定のチームに固有のプロセスに従っている場合、自動化は、チーム外の人々に期待値を伝える手助けをすることができます。例えば、他の多くのチームがあなたのチームのレビューに依存している場合、レビューを依頼されたプルリクエストに自動的にコメントを残し、著者にいつまでにフィードバックがもらえるかを伝えるボットを使用することができます。
良いコードレビューと悪いコードレビューの違い
良いコードレビューは、明確さを増し、コードを開始時点よりも良い状態に押し進めます。
レビュー担当者として、コミュニケーションの明確さが鍵です。あなたのコメントの中で、個人的な好みであるものと、承認のためのブロッカーであるものを明確に区別する必要があります。自分が提案しているアプローチの例を示すことで、コードレビューの質を高め、意図をより明確に伝えることができます。同じリポジトリ内からの例を提供できればさらに良いです。それは、一貫した実装を促すことによって、提案をより強力にサポートするからです。
一方、悪いコードレビューは明確さに欠けています。たとえば、コメントのない全体的な承認や拒否は、プルリクエストの著者にレビューが十分に行われたかどうかを疑わせることになります。プルリクエストの著者の意図を確認するために、承認時にあなたの理解を再確認するだけでも、著者とレビュアーが同じ理解をしているかどうかを明らかにすることができます。
また、提案を実装するタイミングが不明確なコードレビューも、著者にとっては不快な経験となることがあります。既存のコードが変更されていない部分についてリファクタリングを提案することや、追加のケースに対応することを指摘するのは問題ありませんが、それが承認の前提条件であるかどうかを明確にすることが重要です。プルリクエストがそのままでも承認可能であれば、そう述べてください。小さな差分を維持し、これらの変更を別のプルリクエストで出荷する方が安全な場合もあります。
ここでは、具体性と明確に提案された実装を示すコードレビューコメントの例を紹介します：
「あなたの新しいメソッドは、このファイル内の既存のスタイルに従っていますが、[X]個のパラメータを取っています。パラメータが多すぎると可読性が低下し、メソッドが多くのことを処理していることを示唆します。これと既存のメソッドをリファクタリングして、取るパラメータの数を減らすという後日プルリクエストを出すのはどうでしょうか？」
このコメントが良い点：
- 具体的な詳細を提供している。
- 特定のコードや問題に言及している。
- 問題の解決策を提案している。
- 証拠を引用するか、説明を提供している。
反対に、改善の余地があるコードレビューコメントの例をいくつか紹介します：
「これが好きじゃない。」— レビュアーは何が気に入らないのか？明確な代替案があるなら、それを明示的に述べるべきです。
改善案の例：
- 「この行は多くのことをしているので、可読性を向上させるために簡素化できませんか？」
- 「これにはn+1クエリが発生する可能性があるため、パフォーマンス上の問題が発生すると思います。」
- 「この部分はカスタム実装を避けて、[推奨フレームワーク]のソリューションを使用できませんか？」
「これは動作しない。」— なぜ変更が機能しないのか？
改善案の例：
- 「これは[X]のために動作しません。関連する問題はこちらをご覧ください：[issue link]」
- 「これが[X]のために以前に試みられたことがありました。[プルリクエストリンク]では、この問題のために機能しませんでした。」
- 「[X]に問題がある場合、[代替アプローチ]を試すことができます。」
「このバグを修正すると思う。」
— このコメント自体は良いですが、もっと明確にするための追加のコンテキストがあればより良いです。たとえば、関連する問題のリンクを提供することができます。
改善案の例：
- 「これは[issue link]を修正すると思います。」
- 「これは[issue link]のバグを修正していますか？」
- 「これは[リンク先の失敗したビルド]のバグと一致しているようです。修正してくれてありがとう！」
良いコードレビューの提供方法
質問をする
プルリクエストの著者は、プルリクエストで行っている変更について最も多くの文脈を持っている人物だと考えています。私は、自分の経験に基づいて問題を指摘することができます。例えば、Ruby on Railsのモノリス、TypeScript、または大量のトラフィックがあるデータベースを扱ってきた経験などです。しかし、私は著者の回答を信頼し、彼らの理解が私の理解よりも正しいと考えています。
提案
新しいコードベースやチームに加わった場合、コードレビューで質問をして、技術スタックや内部ツール、ライブラリについて学ぶことをお勧めします。レビューするプルリクエストは、著者がなぜあるアプローチを選んだのかを知る絶好の機会です。
また、コードの前提条件について質問するのが好きです。彼らが扱っているデータの形状は何ですか？その形状に一致しないデータは存在しますか？そのコードはそれに適切に対応しますか？リソース集約的ですか？パフォーマンスは良好ですか？レビュー担当者として、私が一番好きな回答は、著者がそのシナリオでの動作を検証する自動化テストを提供してくれることです。次に好きな回答は、例えば、データウェアハウスのクエリやDatadogのグラフなど、なぜそのシナリオが問題ではないかを示す実証データです。
プルリクエストの著者としては、質問を受け取ることに感謝しています。質問を受けることで、なぜその変更に自信を持っているのかを説明する機会が生まれ、必要に応じて問題やクエリ、グラフを引用できます。また、これによって他のレビュアーや、過去の決定の背景を追いかけている将来の読者と知識を共有することができます。
肯定的なコメントをする
質問をするだけでなく、プルリクエスト内で同意する部分にもコメントを残すのが良い習慣です。これらのコメントは、あなたが変更を読み、理解したことを強調したり、コード内の何らかの仮定を確認したりするために役立ちます。いくつかの例を挙げます：
- 「他のクラスで使用されているパターンに一致しているようです。」
- 「このためのテストを追加してくれてありがとう！」
- 「以前よりもはるかに可読性が向上しています。」
私の経験では、このようなコメントを受け取るのは単純に気持ちの良いものです。コードレビューを受けるのは時に疲れることがありますが、多くの質問や提案を受けている中で、何も要求されず、すでに行った作業を支持し認めてくれるコメントがあると、ちょっとした心の励みになります。
バイアスや仮定に注意する
レビュアーや、彼らが変更しているコード領域に対するバイアスがレビューに影響を与えることは簡単に起こります。誰かが特定の領域で作業していることや、ある程度の上級者であることに慣れてしまうと、その人が何をしているかを知っていると仮定してしまうことがあります。しかし、誰でもミスを犯します。変更に対するあなたの目、仮定を確認するための質問、または自分の仮定を検証することが、問題がデプロイされる前に発見される手助けになります。
承認するか否か
レビューを承認するかどうかを決めることは、私が他の人が製品を改善するのをブロックできるゲートの役割を果たすため、慎重に行っています。私は個人的な好みがあることがよくあり、オプションの変更を提案することが多いですが、それだけで承認を保留にすることはしません。他人のプルリクエストに提案をしても、そのプルリクエストがそのままで本番環境に影響を与えたり、ユーザーに悪影響を及ぼすことがない場合は、提案をコメントとして残して承認します。著者は、私のフィードバックに従ってプルリクエストをマージする前に修正するか、別のブランチで修正を続けることができます。
提案
機能フラグを使用し、プルリクエストを小さくしましょう。変更が小さければ、本番環境で簡単に元に戻すことができ、承認も早くなります！
コードをレビューする際に、提案の重要性を考慮しましょう。
あなたの提案を反映させるために出荷を遅らせる価値はありますか？フィードバックを受け取った著者が、提案を反映させるためにコードを修正し、CIを再実行し、再レビューし、デプロイして最終的にマージするというサイクル全体をやり直す必要があるかを考えてください。その提案が欠けていても、誰かの仕事に大きな影響を与えないのであれば、著者がその変更をいつ、あるいはどのように行うかは彼らに任せてください。
「Request changes」オプションを使うと、レビュアーが承認するまでプルリクエストがマージされなくなりますが、私はこれを非常に慎重に使います。これは通常、あまりに強硬な手段だと感じるからです。私はチームを信頼しており、プルリクエストの承認を自分の代わりに他のチームメイトが行うことを問題視しません。また、プルリクエストの著者が私のフィードバックを尊重し、他の誰かが承認したからといって盲目的にマージすることはないと信じています。「Request changes」を使うのは、即座に修正が必要なセキュリティ問題があると考え、著者がマージする前に私の懸念を確認できるかどうか心配なときぐらいです。
AIコードツールを使用する際のコードレビューの重要性
AIによるコーディングツールには、誤ったコードやセキュリティに問題のあるコードを防ぐためのさまざまな安全策が組み込まれていることが多いですが、これらに過信するのは禁物です。最終的に、そのコードのレビューを行うのは人間であり、常に同じレベルの慎重さでコードを確認すべきです。
コードレビューを最大限に活用する方法
自分のコードをレビューする
GitHubのシニアソフトウェアエンジニアであるPaul Smithから学んだのは、他人にレビューを依頼する前に自分のプルリクエストをレビューするということです。そして、私はこれを強くお勧めします。まず最初に自分で確認し、非自明な変更や、他人のプルリクエストで見た場合に自分が質問するような箇所にコメントを残しておくと良いです。セルフレビューは、プルリクエストが大きすぎるかどうかを判断し、分割した方が良いかどうかを見極めるのにも役立ちます。
ポストマージレビューを歓迎する
もし私がプルリクエストをマージしてしまってから誰かがレビューを行った場合でも、そのレビューは歓迎します。もし私のプルリクエストが何かを壊したり、意図しない結果をもたらした場合、そのコメントが将来の読者に手がかりを提供し、何が起こったかを追跡するのに役立ちます。
マージ後にレビューを受け取った場合、私はそのフィードバックを、プルリクエストがマージされる前と同じように扱います。場合によっては、コメントを残して私の視点を説明したり、プルリクエストに対して追加の修正を行ったりすることもあります。また、新しい問題を立てて、追加作業が必要なことを記録することもあります。
ドラフトプルリクエストを活用する
新しいプルリクエストを作成するとき、プルリクエストをドラフトとして設定するオプションがあります。私はレビューを求めるかどうかを示すためにドラフト段階を多用しています。例えば、必要なCIビルドが失敗していたり、まだ作業が完了していない場合、ドラフトのままにしておきます。私は他の人のプルリクエストにも同じことを期待しています：もしそれがドラフトなら、著者はレビューを求めていないと仮定します。レビュー準備が整っている場合は、十分な承認を得ることが唯一のリリースに向けたステップだと考えます。
ドラフトステータスはプルリクエストが未完成であることを意味するため、マージコンフリクトを解消する際やレビュー担当者のフィードバックに対応する際には、プルリクエストを再びドラフトに戻します。もしコードを修正する必要がある場合、レビューを既に終えた人を圧倒しないよう、まずプルリクエストをドラフトに変更します。そして「レビュー準備完了」に戻すと、そのレビュアーにGitHub通知が届き、再び確認してもらうことができます。
丁寧さを心がける
「ハチミツでハエを捕まえる方が、酢よりも簡単」という表現を思い出します。私は自分のプルリクエストがレビューされることを望んでいるので、自分のプルリクエストへのコメントには返信するようにしています。特に、レビュアーと意見が異なる場合には、なおさらです。コメントに返信しない場合でも、👍などのリアクションを使って、同意を示したり、❤を使って感謝の気持ちを伝えたりします。
レビュアーが提案を忘れられないように、コメントを通じて進捗状況を共有します。レビュアーの提案に同意していても、現行のプルリクエストではなく後続のプルリクエストで対応することもあるため、その場合にはその旨を述べます。そして後続のプルリクエストでフィードバックを反映させた際には、リンクを提供してレビュアーに知らせます。こうすることで、フィードバックが無視されていないことを示し、レビュアーの信頼を得ることができます。
その後、提案を実装したプルリクエストにレビュアーをタグ付けし、「これは @so-and-so の <前回のプルリクエストURL> のフィードバックを反映しています」とコメントします。これは他の読者にとってもコンテキストを提供し、元のレビュアーへの感謝の意を示すことにもなります。
フィードバックに対して後続のブランチで対応するという約束を守ることは、レビュアーとの信頼関係を築くのに役立ちます。これにより、レビュアーは将来のプルリクエストも安心して承認できるようになるでしょう。なぜなら、彼らが知っているのは、あなたが何かを中途半端に放置することなく、適切に対処してくれるということだからです。
まとめ
コードレビューは、製品の品質を確保する上で非常に重要であり、特にAIによるコード生成が進んでいる今、その重要性は増しています。私のキャリアの中で、コードレビューのおかげでバグが発見されたり、事故が未然に防がれたりしたことが何度もあります。日々のレビュー、プロセスの洗練、自動化の構築に費やす時間は十分に価値のある投資です。開発者にとって、プルリクエストを徹底的にレビューすることは、問題が本番環境に出てから対処するよりも、はるかに迅速かつ楽な方法です。
Discussion