2013/01/25

プログラムの手入れ

バグを直すついでに周辺のコードを眺めていると、 数年前に書いたコードが妙に野暮ったく見えることがよくある。 ここ数年の経験からより素直な書き方を見つけていたりとか、 最近作ったうまい抽象化をするユーティリティがここでも使えると発見したりとか。 あるいは、数年前には気にしていた制約、性能や互換性の問題が、 今やもう問題ではなくなっていて、 そのため制約を避けるまわりくどいコードをばっさり削れるのに気づくこともある。

そういう細かな修正をやっていると、なんだか庭や畑を手入れしているような、 あるいは(より大きなコードベースでは)裏山の雑木林を手入れしているような気になる。

コードというのはビットの塊で、一度書いて保存すれば永久にそのままだ。 草木のように勝手に生い茂ったり、土砂のように雨で流れたりするわけじゃないし、 金属のように錆が出たりするわけでもない。 それなのに、同じような感覚を覚えるというのはおもしろい。

コード自身は変化しないけれども、コードを読み書きする自分とか、 コードを取り巻く環境が変化しているので、相対的にまるでコードが勝手に 埃だらけになって錆が浮いてたり蔦が這ってたりするように見えるわけだ。

そういった意味ではコードは十分「ナマモノ」だと思う。確かに、時には20年30年という 単位で使われ続ける、セコイアの大木のようなソフトウェアもあって、 その木の上に独自の生態系を築いていたりする。その生態系の住人にとっては 足元の大木は大地と同じくらい確実なものだろう。けれど気づかないうちに、 大木には大きなうろが開いているかもしれない。

しばらく前に、とある歴史あるライブラリが特定の入力パターンで遅くなるというのを 見つけて、ああこれは良いアルゴリズムを知ってるからいっちょやったるかとソースを覗いたら、 TAGBODYとGOとSETQがてんこもりでそっとEmacsを閉じた。 明らかに完全に書き直した方がいいけれど、現状と同じだけコードを「枯れさせる」まで 面倒を見る気も起きない。でもそういう細かいことが積み重なって、 うろが広がってゆき、いつか倒れるのかもしれない。 (何十年と安定して使われ続けてきたコードでも環境が変わればバグが出ることがあるので、枯れたコードが安定した地盤になるという保証はない。)

これまた庭や裏山と同じで、誰かが常に「気にかけていること」が重要なのだと思う。 特に理由がなくても定期的に見回って、散らかっていると思えば片付け、 風通しを良くして空気を入れ替える。時々意味もなくGaucheのコードを眺めては 古くさいインデントを直したりするのは、そういう類の手入れなんだと思う。

でもこういうあんまり直接的な意味が無い作業って、 頼まれ仕事の「他人様の」コードだとちょっとやりづらい。 そのコードの成長をずっと見ていて、これからもずっと自分が面倒みてゆくと 思っている人だからこそ見えるものってのがあるし。

プログラムは表現の手段として、小説や音楽などの表現と並べて語られることがあるし、 私も類似性をよく見出すけれど、この「ナマモノ」感はちょっと他の表現手段と違うかもしれない。 ロングランの舞台とかは近いかもしれないが。 (あと、ソフトウェアでもコンソールゲームのようにリリース時点で固定されるものもあるから 境界は曖昧だけど)

これはソフトウェアが「書かれた」だけで 完結するものではなく、「使われること」で完成するからかな。 その点では音楽や戯曲が「書かれる」だけでは完結せず「演奏/上演」を必要とするのに 似ているけど、音楽や戯曲は最終的な受け手以外にperformする人がいるのでまたちょいと違うか。 ソフトウェアの場合、最終的な受け手が「使う」わけだしな。

Tag: Programming