学生時代、先輩からこんな話を聞いた。「ご飯というものは理論上、無限に食べることができる。なぜなら、どんなに満腹でも米ひとつぶなら食べられるからだ」
ソフトウェア開発の世界でもこの法則は当てはまるかもしれない。プログラムは理論上、無限に拡張できる。なぜなら、どんなに肥大化していても一行だけなら追加できるからだ。
以前に仕事で、1万行に肥大化したC++のファイルに出くわしたことがある。拡張に拡張を繰り返して、ひとつのクラスでなんでもかんでもやっている複雑なコードで、300行程度の関数もごろごろ転がっていた。しかもそのうち2つはほとんど同じで微妙な違いしかなかったりする。ファイルが巨大だから、少しいじるだけでもコンパイルに時間がかかった。
さっそく分割に乗り出したが、そんなことに時間を使うより、さっさと必要な機能を足す方がよい、という話になった。残念な気分になりつつも、必要な機能をどうにか足して、このファイルのことは忘れることにした。
そんなことがあったので、ああいうコードは自分では絶対に書かないようにと思っていたのだが、ふと気づくと自分のプロジェクトの中に 6,000 行のファイルが誕生していた。スケジュールの都合もあったし...、などといろいろ言い訳はあるが、この巨大なファイルをいじくるのはきつくなってきたので、開発が一段落したところで一念発起して分割に乗り出した。
作業はそれなりに難航したが、段階的に分割が進んで 2,000行弱くらいに落ち着いた。まだ大きい気はするが、だいぶ見通しがよくなった。
分割して見通しがよくなってめでたし、なのだけど、一方で、分割しすぎるのもそれはそれで見通しが悪くなるので、どのくらいの粒度がちょうどいいのかはよくわからない。C++の場合、なんとなく、300行くらいはグッド、1,000行くらいまではOKという感覚がある。根拠は全然ないが。
分割で失敗したのは Emacs の設定ファイルだ。以前に、肥大化した設定ファイルをがんばって分割して知人に自慢したところ「なんで分割なんてするの？1つのファイルに入ってた方がサーチとかしやすいし、見通しがいいんじゃないの?」と言われて、確かにそれも一理あるな、と思った。
結局、この設定ファイルは不要な部分を削って1ファイルに戻した。見通しをよくするには、分割するより無駄な部分を削る方がだんぜん効果的なのだ。プログラムの場合なかなかそうはいかないが、無駄なコードを大量に消せたときの気分は爽快だ。