理解することが書き直すことを意味するとき

Jeff Atwood / 青木靖 訳
2006年9月18日

開発者に時間をどう使っているか聞いたなら、彼らはほとんどの時間コードを書いていると答えるだろう。

しかし、ソフトウェア開発者が時間を実際どう使っているか観察したなら、ほとんどの時間をコードの理解に使っていることがわかる。

ピーター・ハラムがこのことについて説明している。

どうしてコードを新規に書くより5倍もの時間をコードの修正に使っているのか? それは新規のコードはほとんどすぐに古くなるからだ。何か新しくコードを書く。コーヒーを飲んで一服する。すると突如として、コードは古いコードになっている。できたてのコードはせいぜい初期のデザインしか反映していないが、デザインの多くの部分は前もって現われるものではない。開発プロジェクトの多く が反復的開発手法を使っている。デザイン、コーディング、テスト、繰り返し。たくさんの繰り返し。すべてが新しいコードなのは最初のイテレーションでのコーディングだけだ。最初のイテレーションが終わると、コーディングは新しく書くよりも修正作業の割合が増えていく。また、バグ修正におけるコーディングもほとんどがコード修正のカテゴリに入る。Visual Studioの開発チームを見るといい。安定化(つまりバグフィックス)のマイルストーンは新機能のマイルストーンと同じくらいに長い。コード修正は、新規のコードより もプロの開発者の時間のずっと多くの部分を占めている。

コードの理解にコード修正の3倍もの時間が費やされているのはなぜか? コード修正をする前に、それが何なのか理解する必要があるからだ。これは既存のコードのどんなリファクタリングについてもあてはまる——リファクタリングで意図しない変更をしてしまわないように、コードの振る舞いを理解しておく必要があるのだ。デバッグでは、問題の修正自体より問題の把握に多くの時間がかかる。問題を修正した後は、新しいコードを理解して、修正が正しいことを確認する必要がある。新規にコードを書く場合でさえ、まったくスクラッ チからやるわけではない。そのコードのかなりの部分は、既存の他のコードの呼び出しになっている。それは自分たちで書いたコードかもしれないし、Microsoftやサードパーティの提供するソースコードのないライブラリかもしれない。そういった既存のコードを呼び出すときには、前もって詳細を正確に理解しておく必要がある。私が最初のXMLアプリケーションを書いた時、XMLを扱うクラスライブラリについて詳しく知るためにコードを書くよりも多くの時間を使 うことになった。新機能を追加する時でも、再利用できるところがないか既存の機能を理解する必要がある。コードを理解するというのは、プロの開発者が時間の大部分を使っている活動なのだ。

多くの開発者がコードを｢理解｣するのは、それを書き直すことによってだと思う。ジョエルはコードを書き直すのはいつだってまずい考えだと思っているようだが、私にはそれほどの確信はない。 ｢ホーキング、未来を語る｣によると、リチャード・ファインマンが死んだ時、彼の黒板にはこう書かれていたそうだ。

私は自分に作れないものは、理解できない。

別に開発者が何でもかんでも書き直したがっていると言っているわけではない。ただ、コードを書き直さずに理解できる開発者というのはごくわずかしかいないということだ。私はコードを読むことの価値を強く信じているが、同時にいいコードが書けるようになる唯一の方法はコードを書くことだと思っている。それもたくさんのコードを。いいコードに、悪いコード、その間のすべて。開発者が(また)車輪を再発明することを望んでいる人はいない。しかし車輪の仕組 の解説を読むというのは、自分で作った車輪を乗り回す経験には遠く及ばない。

他の人の書いたコードを理解する——それがどう組み合っているのか本当に理解する——には、膨大な精神的努力が必要となる。しかし、ソースコードは本当にアプリケーションを理解する最良の方法なのだろうか? 考えることを促されるネイト・コームのブログ記事を読んで以来、 私はずっと考えている。

World of Warcraft (WoW)のルールを理解しようと思う火星人は、ソースコードを見るべきなのだろうか、それとも何百万時間分ものスクリーンキャプチャを見るべきなのだろうか?

レジナルドは面接でこんなことを聞いている。 ｢モノポリーのソースコードを読めば、モノポリーのプレーの仕方がわかるだろうか?｣

この問はある意味で"uphill analysis"より"downhill synthesis"に利点があることを示唆している^†。WoWのルールを実際に知っている人は、無数のファンサイトの分析と試行錯誤によって学んでいる。開発者は本当に知っているのだろうか?

†Braitenberg's law of "uphill analysis and downhill synthesis": 何かの機構をスクラッチからデザインするほうが、自然はそれをどのように作り出しているか解明するよりも容易である。

私はたくさんのアプリケーションを扱ってきたが、自分で書いたソースの助けがあってさえ、そのアプリケーションが正確にどう機能するのか説明するのには困難を感じる。3人、5人、あるいは20人の開発者が関わっている場合には、その説明がどれほど難しくなるか考えてみるといい。

ソースコードは本当にアプリケーションについて物語ってくれるのだろうか? 私には何とも言えない。あるいはアプリケーションについて理解する最良の方法は、逆説的ではあるが、ソースコードをまったく無視してしまうことなのかもしれない。何かのアプリケーションが実際どう機能するのか知りたいなら、ユーザがどう使っているか注意して観察することだ。そしてそのアプリケーションを自分で書いてみることだ。