レビュー とは？

間違いを見つけるだけではないよ。設計が用途に合うか、動作やテストは適切か、後から読む人に分かるかも確認する。コード以外の設計書や資料も対象になる。見る目的と観点を共有すると、必要なことを話し合いやすくなるんだ。

自己点検に加え、別の人が変更を読むことで、見落としや伝わりにくさに気づける場合があるよ。Googleのコードレビュー資料も、作成者以外がコードを調べる活動として説明している。自動テストやツールの検査も組み合わせ、1つの方法だけで品質を保証しないことが大切だね。

成果物を良くするための意見として扱おう。指摘する側は、人を否定せず「この条件だと何が起こるか」のように理由を伝える。必須の修正と任意の提案を区別すると、受け取る側も判断しやすい。良い点があれば、その理由も共有できるよ。

どの変更にも共通する最適な行数はないよ。Googleの資料では、理解するのに必要な情報がそろった、1つのまとまった変更を勧めている。関連するテストや説明を含め、無関係な変更は分けよう。行数だけを小さくして、意味が分からなくなっては困るね。

承認、変更の統合、公開やデプロイはそれぞれ別の段階だよ。指摘を直したら必要な再確認を行い、チームの決まりに沿って統合する。その後のテストや公開方法も確認しよう。レビューの結果や判断理由を残すと、後で変更を理解する助けにもなるんだ。