レビュー中のCLを詳しく見る
何を確認すべきかが分かったら、これからは効率的にコードを分析する順序を見てみよう。
第１段階：巨視的な視点から見る
CLの説明文を読み、何をするCLかをまず把握する。もし不要な作業だったらすぐにその理由を説明する。そして、このような場合には代代案を一緒に提示すれば良い。例えば、「丁寧にコードを修正してくれてありがとうございます！ただ、私たちはFooWidgetを完全に削除する方向に進んでおり、その部分は追加的に修正したくありません。代わりにBarWidgetクラスをリファクタリングできますか？」
レビュアーは礼儀正しく、CLを拒否し、代案を提示した。相手と意見が違っても、私たちは常に相手の開発者を尊重しなければならない。ただ、このように拒絶されるCLが思ったより多い場合は、チームの開発プロセスを一度見直して手間をかけて作成したコードが捨てられないようにし、むしろ本格的に開発に乗り出す前に拒否するようにする。
第２段階：コア部分を見つける
最も多くのロジック変更が発生したファイルを見つける。そこがCLの中核部分だ。 ここからコードを読むと、残りの小さな部分をより早く理解できる。CLが大きすぎてコア部分を見つけるのが難しい場合は、作成者に尋ねるか、CLを複数のCLに分割するように要請する。
コア部分の設計が間違っている場合は、残りを全て見る前にすぐに通知する。残りの部分は、設計を変更しながら自然に消える可能性が高い。 設計問題をできるだけ早く伝えるべき理由は次のとおりだ。
一般に、開発者はコードレビューを要請してから、そのCLに続いて他の作業を開始するため、設計を遅く修正すると後で修正しなければならないコードが益々多くなる。コードの設計を変える作業は時間がかかる。締切も守る必要があるため、期間内に品質の良いコードを作成するには、一日早く再設計を開始する必要がある。
第３段階：残りの部分も適切な順番で確認する
巨視的なコード設計に問題がなければ、残りのファイルも詳しく確認する。 コードレビューツールでソートされている順番通りで見てもよく、テストコードから見ても役に立つ。