博士

やあ、ロボ子。今日はコードレビューについて話すのじゃ。

ロボ子

コードレビューですか、博士。エンジニアは敬遠しがちだと聞きますが、なぜでしょう？

博士

ふむ、PRが大きすぎたり、複雑すぎたりすると、レビューが大変になるからのじゃ。セキュリティリークのリスクもあるし、コードが保守不能になることもあるからの。

ロボ子

`git blame`で責任の所在を特定できるとはいえ、システム全体に対する責任は全員にあるべきですよね。

博士

その通り！そこで、レビューしやすいPRを作るのが重要になるのじゃ。平均的なレビュー担当者が5-10分でレビューできるPRを目指すのじゃ。

ロボ子

具体的には、どうすれば良いのでしょうか？

博士

まず、PRの範囲を狭めるのじゃ。変更行数を300行以下に抑えるのが理想的じゃな。500行を超えるとレビューが難しくなるからの。

ロボ子

なるほど。それから、コミットメッセージも重要だと。

博士

そうじゃ！コミットでストーリーを語るのじゃ。変更を段階的かつ論理的に提示して、レビュー担当者が思考プロセスを追えるようにするのじゃ。

ロボ子

「依存関係の追加」のような曖昧なメッセージは避けるべきですね。

博士

その通り！Saša Jurić氏の例では、152行のコード追加と2行の削除を、13個の思慮深いコミットで構成したそうじゃ。

ロボ子

すごいですね！それぞれのコミットが、なぜその変更が必要なのかを明確に説明しているんですね。

博士

そして、反復プロセスも大切じゃ。テストで予期しない結果が出たら、コードとコミットを更新してストーリーの一貫性を保つのじゃ。

ロボ子

`git fixup`を使って、以前のコミットを修正することもできますね。

博士

そうじゃ！クリーンなコミット履歴は、`git bisect`を使ってバグが導入されたコミットを特定するのにも役立つのじゃ。

ロボ子

すべてのコミットがコンパイル可能で、アプリケーションが実行可能な状態を保つことが重要ですね。

博士

まさに！焦点を絞ったPRと明確なストーリーを伝えるコミットを提示することで、フィードバックが迅速になり、開発サイクルが加速するのじゃ。

ロボ子

PRを作成する際は、まず小さなことから始めるのが良さそうですね。300行以下に保つ、記述的なコミットメッセージを書く、など。

博士

そうじゃ！レビュー担当者が理解できるストーリーを語ることが、共同作業の成功につながるのじゃ。

ロボ子

勉強になります、博士！

博士

ところでロボ子、コードレビューで一番大事なことは何だと思う？

ロボ子

えーと、バグを見つけること、ですか？

博士

ブー！それはもちろん大事だけど、もっと大事なのは、レビュー担当者に「このコード、私にも書けたかも！」と思わせることなのじゃ！

ロボ子

え？

博士

そうすれば、レビューも楽しくなるし、コードも良くなる！…たぶん。