女性向けエンジニアスクール
3秒でわかる
書いたコードを別の人が読み、取り込む前に問題や改善点を指摘し合う工程。欠陥を早く見つけるだけでなく、書き方の基準をチーム内へ広げる役割も持ちます。
もう少し詳しく
どういうものか
コードレビューは、変更を本流へ取り込む前に、作者以外の開発者がその差分を読む工程です。多くの現場ではプルリクエスト (マージリクエスト) の形で行い、行単位で指摘を付け、承認されてから取り込みます。
見る観点は 4 つに整理できます。仕様どおり動くか、異常な入力で壊れないか、後から読んで分かるか、既にある仕組みと重複していないか、です。動作の確認は自動テストに任せ、人は後の 2 つに時間を使うほうが効率が上がります。
なぜ必要か
欠陥は、見つかるのが遅いほど直す費用が上がります。レビューで見つかれば数分の修正ですが、本番で見つかれば調査、修正、再デプロイ、そして利用者への説明まで必要になります。
もう 1 つの効果は、知識が 1 人に閉じないことです。ある機能を書いた人しか中身を知らない状態は、その人が休んだ日に手が止まります。レビューを通すと最低 2 人がその変更を把握します。新しく入った人にとっては、指摘を通じてチームの書き方を学べる場にもなります。
具体例
指摘の書き方の例
[must] 5 行目 ユーザー入力を文字列連結で <a href="/glossary/sql" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">SQL</a> に入れています。
プレースホルダーを使ってください。
[imo] 22 行目 3 段の入れ子になっています。早期リターンにすると
読みやすくなりそうです。
[nits] 40 行目 変数名 tmp2 が用途を表していません。
[ask] この分岐に入るのはどんな場合ですか。テストが無いようです。先頭に印を付けると、直さないと取り込めないものと、好みの提案が区別できます。受け取る側が判断に迷わず、やり取りの往復が減ります。
つまずきやすいところ
差分が大きすぎるレビューは機能しません。1000 行の変更が来ると、読む側は細部を追えず「良さそうです」で通してしまいます。数百行までに区切って出します。
指摘の書き方も問題になりがちです。「ここが分かりにくい」だけでは相手が動けません。何がどう分かりにくく、どう変えると良いかまで書きます。逆に受ける側は、指摘をコードへの評価と受け取り、人格への評価と混同しないことが必要です。
反応が遅いのも実害があります。半日放置されると作者は次の作業へ進み、指摘を受けても戻るのが億劫になります。
似た用語との違い
静的解析ツールは書式や明らかな誤りを自動で指摘します。機械にできることは機械へ任せ、人は設計の妥当性に集中するのが現在の分担です。ペアプログラミングは書きながら同時に見る方式で、レビューの待ち時間が無い代わりに 2 人の時間を同時に使います。
覚え方
レビューは作者を試す場ではなく、コードを良くする場です。主語をコードに置くと指摘の言葉が変わります。
