developerWorks 6/19～25のランキングで1位になった記事で書けなかったこと

IBMdeveloperWorksに寄稿した記事「コードレビューの道具、使っていますか？」が6/19～25のランキング1位になった。今週はそのランキングをここからみることができると思う。この記事で時間が足りず書けなかったことがいくつかある。そのうちの1つをこのエントリで紹介したいと思う。

記事には「ソースコード静的解析ツールでレビュー箇所を見極める」という見出しの中で静的解析ツールを使って重点的にコードレビューすべき点を特定する、という内容を書いている。これに加えて、コードを書きながら静的解析を実施すればさらに効果が高まるということを書きたかった。（が、時間が足りず書けなかった。。）

具体的には、ソースコード編集ツールやIDEでソースコードを書いているうちから都度メトリクスを測り、複雑なコードになっていないか等のチェックを書きながら進めていく。必ずしもソースコードを編集しながらやる必要はなく、Jakarta Mavenのようなビルド管理、構成管理ツールで、ソースコードをチェックインするたびにメトリクスを計測し、その都度メトリクスを見るパターンもある。

都度メトリクスを測り、見ることで、自身のコードの保守性、拡張性、テスト容易性を確保するために役立つ。たとえばソースコードメトリクスとして有名なサイクロマチックナンバを計測すれば、不必要に複雑な分岐を作っていないかという点を比較的客観的に調べることができる。他にも外部からの参照が非常に多い部分かどうかを測るメトリクスがあり、その値が高い部分を編集していれば、潜在的変更リスクが高い部分を編集していることがわかる。

ソースコードメトリクスはソースコードの特徴を数値化したもので、この値からすぐに不具合箇所がわかるというようなものではないが、そこから得られるヒントは大きい。

元の記事に書いたようにまずはコードレビュー実施中、あるいは実施直前の計測、それができるようになればコーディング中での計測とそれに応じた対応をとれば、早期に潜在的問題を修正できる可能性が高くなる。