プログラミングの光景 - コードレビューについて

最終更新日: 2007-08-25

WEB+DB PRESS Vol. 41 に向けて書いた記事の元の原稿です。


「プログラミングに関する雑多な事柄」がテーマの本連載、第4回の今回は「コードレビュー」について取り上げたいと思います。

コードレビューの方法

コードレビューは、文章のレビューと似ています。文章と同様に、コードの場合も、人に見てもらうことで、わかりづらい部分や、冗長な部分、内容が間違っている部分など、さまざまな問題点が見つかります。

自分の書いた文章を人にレビューしてもらうには、たとえば、文章をメールで送ります。この場合、レビューのフィードバックはメールの返信という形で受け取れます。あるいは、印刷したものを手渡して、赤ペンでレビューしてもらうという方法もあります。

コードレビューの場合も同様の方法で行えます。コードレビュー用の市販ツールなどもありますが、人に見てもらってフィードバックを得るということが一番大切ですから、特に方法にこだわる必要はないと思います。

コードレビューのメリット

それでは、コードレビューに具体的にどんなメリットがあるのか見ていきましょう。

コメントの充実

コードを書いた本人にとっては当たり前と思えるような処理も、他人から見ると、何をやっているのかよくわからない、ということは多々あります。「ここ、わかりづらいからコメントつけといて」というフィードバックに基づいてコメントを充実させていくと、のちのちのコードのメンテナンスに役立ちます。

あるいは、パブリックなインタフェース (他のコードから呼び出される関数など) に適切なコメントをつけ忘れている場合も「コメントつけといて」というフィードバックによって、コード内のドキュメントを充実させることができます。

変数名、関数名などの改善

コードを読みやすくする秘訣のひとつは、変数や関数にわかりやすい名前をつけることです。「この変数名、こうしたらもっとわかりやすくない?」といったフィードバックによって、名前を改善していくことができます。

私の場合、以前に、「is_data_initialized という変数名より data_is_initialized の方が if 文の中で自然に読めるからわかりやすいよ」と言われて感心しました。確かに、

if (data_is_initialized) {

から記号を除くと "if data is initialized" となり、「もしデータが初期化されていたら」という自然な英語になります。

バグの発見

気をつけてコードを書いてテストを行っていても、うっかりミスで初歩的なバグを入れてしまうことはなかなか避けられません。他人の目を通すと、そうしたうっかりミスをキャッチできます。

それから、不馴れな分野のコードを書いた場合にもよくバグが入ってしまいますが、自分よりその分野に詳しい人に見てもらえば、ありがちな類いのバグは簡単にあぶり出されます。

APIの改善

クラスや関数の使いやすいAPIを設計するのは難しいことです。必要な機能が欠けているのは一番困りますが、呼び出しが煩雑なのも困りものです。コードを共有するメンバーから「○○をする機能が欠けてるんだけど」「この関数、こういう API にした方がシンプルじゃない?」といったフィードバックをもらうことで、APIが洗練されていきます。

リファクタリング

よし汚いコードを書くぞ!といってわざわざ汚いコードを書く人は (特殊な状況を除けば) いません。しかし、そのつもりはなくても、いつのまにか汚いコードになっていたりします。コードレビューを行えば「ここのコード、他と重複しているから関数にしてまとめたら?」「この関数、長すぎるから分割したら?」のようなフィードバックによって汚い部分の洗い出しができます。

ノウハウの共有

ちょっとしたノウハウを知っていれば、短くわかりやすく書けることでも、それを知らないと、煩雑なコードになってしまう、ということがあります。同様に、ちょっとしたノウハウを知らないためにセキュリティ上の問題となるコードを書いてしまう、という場合もあります。

コードレビューはそのようなノウハウを交換するのに非常に有効です。「この関数を使えばもっと簡単に書けるよ」「こういう風に処理すれば安全だよ」といったフィードバックを交換すると、コードの品質が改善されるだけでなく、ノウハウの共有も行えて一挙両得です。

その他

この他にも、コーディングスタイルの統一、パフォーマンスの改善やテストケースの充実など、コードレビューを通じて得られるメリットはたくさんあります。

コードレビューのコツ

自分のコードを人にレビューしてもらうのは、多少の緊張が伴う行為です。「こんなコードは全然ダメだ!」と完全に否定されてしまったら、しばらく立ち直れそうにありません。あるいは、そんなことを言われたらカンカンに怒ってしまう人もいるかもしれません。

こうしたトラブルを避けるには、よく書けている部分をほめたり、断定的な表現を避ける、といったちょっとした気配りが役に立ちます。円滑なコミュニケーションはコードレビューに欠かせません。

それから、「すでにたくさん書いてしまったコードを今さら直せと言われても…」という事態を避けるためには、できるだけこまめにコードレビューを行いたいところです。バグにしても設計にしても早いうちに直す方が安く済みます。

むくつけきコード…
むくつけきコード…
*1

まとめ

今回はコードレビューについて書きました。コードレビューはコードの品質を高める効果的な方法のひとつです。コードレビューにはある程度の時間がかかりますが、効果的に行えば、要する時間よりも、得られるメリットの方が大きいはずです。


*1雲のような吹き出しでお願いいたします