ぼくの歳になるともう脳細胞とか壊れるばっかしだし、あとはもう老化を待つしかないかんじです!!!!! 人間の身体的な成長とか不可逆だし、これから細胞が若返るとかはたぶんだけどない。有機物とかそういうもんだと思うし、世の中の有機物という有機物は、生まれたときから死ぬことが運命みたいだ。
ところでぼくは、保守性が下がるのを老化ということにすると、タイトル通りミッションクリティカルなソフトウェアっていうのもわりとそういうかんじで、サービスインしたときから老化が始まってるんじゃないかって思うところがあったりします。人間とかと違って、もしかするとちょこっと若返ったり(=一時的に保守性が改善されたり)するかもしれない。でも、だんだんとやっぱし保守性ていうのは下がっていうことが運命付けられてるんじゃないかなって思ってしまったりするのです。
止めることが許されないソフトウェアというのはヤバい。動き出してからはできる限りバグを混入させないことが至上命題になっていく。でも、元々混入されていたバグだったり、新しい機能追加だったりというのは不可避です。だから、ソースは触らないといけない。
でも人間にはミスがつきものです。ミスをしない人間というのはいない。ぼくもこの間、自炊しているときに粗塩を玄関に大量にこぼすというミスをやらかしてしまい、お前の家に厄でもついてんの？厄除けのつもりなの？とかそういうかんじだったんですけど、とにかくミスはだれでもします。自分のミスでミッションクリティカルなソフトにバグを混入させるのは避けねばならん。ですから、できる限りそのソースを触ることによる影響範囲を小さくしたい。結果として、綺麗な(保守性を保った)ソースというよりは、付け焼刃的な改修になりがちになる。結果として全体の見通しは悪くなり、バグが混入しやすくなる。
ですけど、じゃぁバグ改修あるいは機能追加で
- キレいなプログラム構造とするためには、ソースの大幅な改修が必要で、それはプログラム全体に影響する
- ソースは汚くなるけど、影響範囲は小さくて済む
なんて状況のときに、プログラムを作る側も、そして使う側も、1. を選ぶのって躊躇するんじゃないかなって思います。もちろん、最終的には自分の首を絞めることになるかもしれない。でも、少なくとも明日は生きられる。プログラムは正しく動いてくれる。10 年後に生きられるかよりも、まずは明日を生きることが重要、明日プログラムが正しく動くことが重要、そういう選択って十分に合理的なような気がします。
こうして、プログラムの保守性は段々と下がっていく。今日明日のバグを乗り切るうちに、10 年後になる。綺麗だったプログラムはバグが混入しやすくなっていき、バグが障害を誘発するようになっていく。そして、「じゃぁ新しく作り直そう」ってなる。これがソフトウェアのスクラップ & ビルドなんじゃないかなと思います。Perl5 が Perl6 になる一つの要因も、はてなブックマークが新しく書き直されたのも、そういう感じなんじゃないかと思います。
進化するソフトウェアって話があるけど、人間も進化は一世代じゃできない。生まれて死ぬのを繰り返して、ちょっとずつ進化していく。後はいかにして死んだ人の得たものを後世に伝えていくか、ソフトウェアであればそのノウハウと、スクラップの中から再利用可能なところをいかに次世代ソフトに生かしていくか、そういう話なんじゃないかと思います。
