システムの柔軟性はプログラムだけで担保しなくともよい

業務的にはいきなりの大波乱を乗り越えて、これを書いています。

例によってあまり詳細なことは書けませんが、急な要件変更があったということです。ただ、今回は予想以上に早く計画を立て直せたので、その点ではちょっと自慢してもいいのではないかと思っています（えっへん）。

さて昨日、レガシーコードには変更に対する柔軟性がないということを書きました。したがって変更に強い設計を行うべきでは、という思いを新たにしたわけですが、今回の急激な要件変更に耐えられた理由は、決して実装側で吸収できたからというわけではありませんでした。具体的には、管理していたドキュメントが現状を表すために機能していたので、それを元に素早く新しい計画を立てることができたのでした。なかなかのお手柄です（えっへん）。

仕様変更に強いシステムと、要件変更に強い管理用資料、両方は別の性質なんでしょうか。ちょっと考えてみたんですが、共通する部分もあるように感じています。結局のところ、システムの構成要素を部品として捉えて、それぞれ個別の動作・状態はもちろんのこと、その構成要素同士の依存、包含関係などを把握しておくことが、システムへの変更依頼があったときに素早くまず現状認識ができるようになる、つまり判断が早くなる、ということかと思います。

ただし、もとのシステムがあまりにも硬直している場合は、状況がうまく管理され、素早く状況を把握したとしても、元々の実装のまずさが明確に浮き彫りになるだけのことで、根本的に対処が早くなるのかという点では別問題です。つまり、管理状況と柔軟な設計はそれぞれ違う役割でシステム全体の対応速度アップに寄与するわけですね。

そういう意味では、どれだけきれいに書かれた実装だとしても、（プログラムを超えた業務要件などに関する）説明用の資料や全体を俯瞰した一覧などがないと、少し判断がもたつくということかもしれません。経験上も似たようなことは思い出します。ただ、業務要件なども、ドメインモデル（DDD的な文脈でのそれです）があれば、ソースコードに「匂わせる」ことはできます。それだけでも、後からソースコードを確認した場合に調査上の安心感が大幅に上昇します。

話を現実から少し浮かせます。そもそもでいうと、ソースコードを書く側はできるだけ手間なく素早く書き終わりたい（そしてビールを飲みたい）わけなんですが、ソースコードを読む側もできるだけ手間なく現在の状況を把握して対応を終わらせたい（そしてビールを飲みたい）わけなんです。しかもその2つの立場を同一人物が体験することも多いです（個人開発など）。だから、プログラミングツールが、こちらが書いた情報を「解釈」したり整理したりしながらソースコードが読み取れる範囲の仕様を常にアップデートし続けることが必要なのかな、と考えています。IDEでも一部そういう機能は、静的解析という形で実現されているとは思いますが、それをもう少し超えたなにかをイメージして書いています。機械学習を使ったコーディング上のサジェストとかも最近見た気がするので、それほど夢物語でもない気もしますが、はてさて、どうなりますかね、ということで、今日も無事に終わったので、ビールを飲みますか。