AWS builders.flushに寄稿した「コードレビューでバグを見つけるときに何をしているか？」の2編のまとめ

コードレビューでやっていることをつきつめると「欠陥を見つける」「将来読むことを想定して、読みにくい部分をみつける」「代替案がないか確かめる」というくらいになります。では、これらがうまくなるには、どうしたらよいでしょうか。これまでたくさんのレビュー指摘をみたり、レビューしたりされたりしてたどりついた私の答えは、対象コードに合わせた読み進め方を選んで、問題がある部分を見つけることです。

欠陥を見つけるのは、本来あるべき実装方法とコードを突き合わせてズレがないかを探しています。ありがちな間違いを覚えていて、そのパターンがあてはまるところを見つけていると言えます。そうしたパターンも「こういうふうに実現しないといけない」と「コードとしてこう書かれている」というズレを見つけていると言えます。

もっともイメージしやすいのは、仕様を「こういうふうに実現したい/しないといけない」ことを表現したものと考え、対応するコードがそのとおりになっているかを確かめることです。他にも期待する性能が出そうか、将来の拡張に向けて変更しやすかったり読みやすくなっていたりするか、といったあたりを確かめることもイメージしやすいと思います。

こうしたズレの探し方を読み進め方と呼んでいます。こうしたレパートリーを積極的に増やしていって、対象コードに合わせてうまく選べるようになれば上達を早めることができます。ここでは触れませんが、指摘のしかた(言い回し)も上手なコードレビューの条件となっています。これもうまくなる必要があります。話が発散するので、この記事ではこちらの条件は省略します。

読み進め方のレパートリーは、他の人のコードレビューでの読み進め方をみようみまねで学んだり、自分のコードをレビューしてもらったりすることで身についたと思います。他にも自分や他の人のバグから学んだり、セルフチェックで気づいたりということもありそうです。読み進め方を意識すれば、こうした機会を積極的に活かして、レパートリーを増やせます。

最近では、コードレビューの一部を自動化しているものもあり、クリティカルセクションに関してリスクのあるコードを指摘できたりします。こうした自動検出では、誤検出(実際には問題がないのに問題があると指摘してしまう)が問題とされていましたが、正しい指摘であったかどうかを人手でフィードバックして機械学習のインプットとすることで、誤検出を減らす仕組みも運用されはじめています。

このあたりを詳細に説明する記事をAWS builders.flashに寄稿し、9月と10月で前編、後編として公開いただきました。覗いてみてください。

前編では、一般的な読み進め方を説明しています。元記事はこちら。

後編ではWebAPIやレビュー自動化についても触れています。元記事はこちら。

私のTwitterでこうしたソフトウェア開発に関する情報を紹介しています。フォローはこちらから。