コラム：開発者が学ぶべきこと（1）
開発者を鍛えるコードのレビュー

Tim Romero（ティム・ロメロ）
2003/1/8

■重要なのはコードを読むこと

　われわれプログラマ（開発者）は、コードを書くスキルを上達させるために多大な時間を費やしているが、コードを読むことに関しては、あまり考えていないものである。多くのプログラマは、自分の仕事はコードを書くことだと思い、他人のコードを読んだりメンテナンスすることは面倒だと考えがちだ。しかし、これはあまりいい状況とはいえない。さまざまな面において、コードを読むことは、書くことよりも重要であるからだ。

　プログラマは、自分がコンピュータのためにコードを書いているのだと思いがちだが、実際はほかのプログラマのためにコードを書いているのである。どんなコードでも、書かれるのは一度きりである。しかしそのコードは、一生涯のうちにコード作成者を含む数多くの人々に何度も繰り返し読まれるものなのだ。コード作成で断言できるのは、ほかのプログラマにとって読みにくいコードはいいコードとはいえない、ということである。他人の書いたコードを読んだり理解するのが得意でないプログラマは、そのスキルを必ず身に付けていくべきだろう。

　残念ながら、コードを読むことは書くことよりずっと困難で、しかも楽しくもない。10人中9人のプログラマは、他人のコードを読むのに15分程度しか時間を費やさないという悲しい現実があるのは事実だ。15分で理解できなければ、その時点でお手上げだといい、そのプログラムを「救いようのないスパゲッティ・コード」だと決めつけて、次の1週間は機能を再実装することに時間を費やすのである。

■コード検閲の利点を考える

　例えば私が設立したヴァンガードでは、コードを読むことは開発プロセスの一部となっていた。すべてのコードは組み込まれる前に必ずほかのプログラマが読み、検閲することになっていたのだ。検閲するプログラマは、そのコードが理解できるものであると確認し、プログラミングのガイドラインに沿っていることを認定する。このプロセスに例外は許されず、コードのコメント内に作成者と検閲者の名前が記録されることになっている。

　このようなコード検閲作業は、あまり広く知られてはいないがとても重要であり、IBMやNASAといったソフトウェアの質が大きく改善されてきたとされている組織では、昔から使われていた方法なのである。NASAのソフトウェア開発ハンドブックには、バグの40％はコード検閲によって発見されたとあり、コード検閲は古くから使われている欠陥を探し出すテストの2倍は有効だと記されている。

　NASAにそのデータを出してもらい、証明することもできるのだが、もっと簡単にコード検閲がソフトウェアの質を向上させるのだということを証明しよう。エンジニアは自分の仕事にプライドを持っているものである。エンジニアがコードに自分の名前を入れ、それがほかのプログラマに検閲され、評価されるのだとしたら、自分のありったけの能力を駆使してコードを書こうという気にもなるだろうし、手抜きをしようなんてことは考えないだろう。

　また、プログラマと検閲者の両方ともが、組み込まれる前にコードを理解しなくてはいけないため、コード検閲の過程で、最低2人のプログラマがシステムのどの部分がどう動くかを理解していることになる。このように、プログラマと検閲者のどちらでも将来的にコードのメンテナンスを行えることになるのだ。これは、鍵となるシステムの知識がたった1人のエンジニアにしか理解されていないという危険を避けることにつながり、また新しいプログラマを訓練するにも素晴らしい方法だといえる。

　XP（eXtreme Programming）スタイルのソフトウェア開発をご存じの読者であれば、これらの利点はXP開発におけるペア・プログラミングと似ていることに気付くであろう。筆者自身はペア・プログラミングよりコード検閲の方がずっと効率的で簡単にできると考えているのだが、両方を試してみて、どちらが自分に合っているか判断してみてもよい。

■コードを読むスキルについて

　では、どうすればコード読みのエキスパートになれるのだろうか？ これには練習しかない。まず他人が書いたプログラムのコードを読むことから始めてみよう。すると、コードを読むことがうまくなるにつれコードを書くことも上達することが分かってくるはずだ。コードを読んでいるときに、そこからアイデアが生まれるという直接的なメリットがあるのはもちろん、自分がコードを書く際、他人に読みやすいコードを書こうという意識が働くようになるという、間接的なメリットもある。これは、いいコメントを出せるようになったり、長い間信じていたことに対して疑いを持つようになり、変化が起こるといった結果になって出てくるようになる。

　例えば、現代コンピュータ科学において抽象化はよいことだとされている。機能は1度しか実装してはいけないといわれるし、コードは決してコピーされるべきではないと教えられる。機能が1カ所でしか実装されないことにより、コードのメンテナンスと変更が簡単になるという理論だ。

　たいていの場合これは正論であり、適切に抽象化されたコードは読みやすいものである。しかし、抽象化が逆効果になることもある。コード変更を1カ所だけで済ますために時間を節約したところで、結局変更しなくてはいけない抽象部分を理解し、その部分がプログラムのほかの部分に与える影響がどんなものかを理解するのに2日もかかっているようでは、まったく意味がないのである。

　また、うまく書かれたコードを読むことはとても楽しい作業であることに気付くだろう。優れたプログラマのコードを読んでいると、物語を読んでいるような気分になるものだ。

■制作環境でのコード検閲

　コード検閲は自由なものなので、制作環境においてどのような方法でコード検閲を行えばいいのかといったルールは決まっていない。しかし、筆者が見てきた成功例の中には共通点が3つあったので、それを指摘しておこう。

　まず1つ目は、組織内に明確なプログラミングガイドが文書として存在するということだ。何をチェックすればいいのか分からないまま、コード検閲をするのは大変難しいものである。もし組織内に文書でのスタイルガイドが存在しないのであれば、コード検閲作業を施行する前に用意することをお勧めする。

　2つ目として、プログラマと検閲者は、ほかの芸術家が皆そうであるように、自分の作品にサインしなくてはいけない、ということだ。すべてのクラス、すべてのメソッドにおいて、組み込まれる前にプログラマと検閲者の名前が記載されていなくてはならない。検閲者がサインするということは、そのコードが組織の基準に従っていることを証明するだけでなく、その検閲者が確実にコードのメンテナンスを行えることを証明するものでもある。

　3つ目は、例外は許されない、ということだ。もしメソッドがコード検閲されなかったり検閲をクリアしなかった場合は、そのメソッドを組み込んではいけないのである。

　コードを読んだり検閲するという方法はまだ一般に知れわたってはいないかもしれないが、やってみればこの方法が、ソフトウェアの質を向上させるのに一番簡単で安価な方法だということに気付くはずである。

筆者プロフィール

Tim Romero（ティム・ロメロ）●米国ワシントンDC出身。1991年に来日し、インターネット金融取引システムなどの開発を手掛けるヴァンガード（Vanguard）を設立。同社がデジタルガレージに買収された後、取締役として2002年9月まで在籍。現在は東京やサンフランシスコの企業とともに、エンジニアリングおよび開発プロセスの改善、技術管理の合理化に向けた活動を行っている。なお、本コラムは不定期での掲載を予定している。最近、新しい事業を始め、エンジニアを募集している。興味がある人はぜひ読んで応募してほしい。