理系学生日記

おまえはいつまで学生気分なのか

忍者TOOLS

アプリケーションのスクラップ & ビルドについて思うこと

「このコードには欠点があるぅぅぅぅ!!!」とまぁミスター味っ子ばりに、洗練されたコードを書くことに命を燃やしている方もいらっしゃると思います。
洗練されたコードには余計な重複が一切なく、スリムな体をしています。いってみれば体脂肪率が 10 % を切るようなヤツで、見たことなくても胸がときめくし、キュンてなるし、スゴくカッコいい。

しかしちょっと考えてみると、余計な重複がないということは、コードの再利用が徹底されていることを意味します。言い方を変えると、様々なモジュールだったり、様々な機能だったりから呼び出されるコード片が多い。これは即ち、当該機能の変更によって影響する機能が多いことを示しています。
既に運用フェーズに入ったミッションクリティカルなシステムの変更には大きなリスクを伴います。従って「既存機能に影響を与えないように」という意識が徹底されて然るべきなのですが、この意識はときに「既存機能に一切触らないように」という原理主義に行き着き、「ほとんどは既存機能と同じだけど、ちょっとだけ別」なモジュールが作成され、改修対象機能からはそのモジュールを呼ぶようにすることで既存機能への影響を 0 にするという方針が打ち立てられがちです。
このような改修が繰り返されることによって、スリムだった体は加速度的にその体積を増し、全体を見渡すことができない、高度で複雑なコードへと姿を変え、いつしかそれはスパゲティと呼ばれるようになります。そもそもミッションクリティカルなシステムの変更にはリスクが伴うのですから、そのスパゲティなコードがリファクタリングなどされるはずもなく、改善は一向に進みません。結果として、保守ができる人間がいつしか消え失せ、「もう保守がムリだから、新しいシステムをビルドしなおしましょう」という提案が成され、その提案がアプリケーションベンダの飯の種になります。

このような非常に歪んだ構造が罷り通るのは、「既存機能に影響を与えないように」という当然の思考が、「既存機能に一切触らないように」という極論に行き着いてしまうことに大きな原因があると思っています。
理想論で言えば、「既存機能に影響を与えないように」というのを担保するのが数多のテストケースであって然るべきなのですが、では、今そこにあるテストケースを全部パスすることで「既存機能に一切影響を与えない」ことが担保されるのか、という問いに答えることは、おそらく誰にもできません。この事実こそが、「既存機能に一切触らないように」という極論に強い説得力と与えてしまうのだと思っています。

ではこの状況を改善するには、というところに話を移そうとすると、上述の "今そこにあるテストケースを全部パスすることで「既存機能に一切影響を与えない」ことが担保され" ないのはなぜなのかという問題への回答が必要になります。これはおそらく、システムが複雑すぎる(状態を持ちすぎる)ことが原因だというのが自分の考えです。システムの持つ状態が多ければ多いほど、各状態のテストに加え、状態間遷移の数は爆発し、テストを書くこと自体が困難になり、保守する人間が死に至るおぞましい現代病が生み出されてしまいます。
KISS の法則が示しているように、システムは徹底的にシンプルにし、必要十分な状態のみを持つようにしないと人が死ぬ。そのようなシステムを提案したところでお客さんに評価されるのかという疑問はありますが、それを評価させるようなアピールができないといけないなと。そんなことを思うのでした。