増1．漏れ抜け考
●今回の発端
以前の「自転車とプログラミングと」で、漏れ抜けについて考えましたが、やはり何も出ませんでした。
あれから自分の文章を読み直したり、他の人の文章を読んだりして考えてみました。
少しまとまったので、ご披露します。
ただ、以前の文章は少なくとも5年は寝かせたネタだったのに対し、こんどのは即興に近いので、ご容赦を。
●まずは、漏れ抜けを離れて...
各プログラミングのシーンにおいて、（それを踏み越えて単純化すると意味がなくなる）必要最小限の複雑さが存在するのでは、ということを考えます。
明示的に「どんな複雑さ」かという事を構成的に示す事は難しいか不可能かも知れませんし、各シーンで複雑さが異なる事も十分有り得ますが、
その複雑さに至るまでは、単純化をすればするだけ誰もが納得する手柄になるが、いったんその複雑さをまたいでしまうと、とたんに“なんだかね”と言われて敬遠されてしまう閾値を考えるのです。
たとえば、筆者はいま漠然と「オブジェクト指向は、必要最小限の複雑さの中だが、ドメイン指向はそれをまたいでしまう存在ではないか」と危惧しています。
●もしまたいでしまうとどうなるか？
もし知らずに（構成的にその複雑さを示せない以上、知らずにまたいでしまう可能性は十分有ります）またいだ場合、起こることとしては下記が挙げられます。
- 外部に示す記述の粒度が粗い。（いままでの文章の経緯より自明。以下、公開表現という）
- 必然的に、必要最小限のより細かい記述を内部表現として持ち、それは公開されない（以下、内部表現という）
- その公開されない内部表現は、それをプログラミングの根拠としてはいけない（公開されていない以上、根拠とできない）
必要最小限の複雑さをまたいだ為起こる、公開表現と内部表現の乖離による弊害について、とりあえず3つ考えました。
●公開表現と内部表現の乖離による弊害 その1
☆同じことを違う場所にプログラムとして記述する。（以下『コピペ』という）
前にやっていた仕事で、「貸し付け処理」と「ある処理で同時に行われる貸し付け処理」を『コピペ』で二重管理していたのを見た事が有ります。
そこでは「業務に基づいた整理」を全面に出していて、（事務フローなどで定式化される）「業務」が最小の複雑さであり、それより粒度の細かい「貸し付け処理」などは“表現してはいけない／表現しても捨てられる／表現しても成果とならない”世界でした。
もちろん、会社の仕事で本当に使われる規模のプログラムにおいて、たった1つがコピペなら問題ありませんが、方針として「業務に基づいた整理」である場合、今後発展していくにつれ、その1つが2つになり、3つになり、耐え難い数になると予想され、その結果、発展されるのを非常に考えづらくしていました。
●公開表現と内部表現の乖離による弊害 その2
☆違うことに同じ名前を付ける。あるいは無名とする。（以下『擬似抽象化』という）
『擬似抽象化』なんて悪意のあるネーミングかと思われるかと思いますが、そう思われても可笑しくないぐらい、筆者はこれが嫌いです。
たしかに違うことに同じ名前を付けたり、無名にしたりすると見かけ上抽象度が上がる（外部に示す記述の粒度が粗くなる）のは事実ですが、それでは2度と保守できなくなります。
無理矢理、公開表現を要求される粒度にしようとすると、こうなります。
勿論、毎回仕様から考え直して自動生成ツールなどでプログラミングをしさえすれば、ネーミングルールをどうしようと無名にしようとかまわないかと思いますが、一旦できたシステムを毎回毎回仕様から考え直そうとする発注者は見たことがありません。
●公開表現と内部表現の乖離による弊害 その3
☆似ていることを集約しないで違うプログラムとして記述する。（以下『みんな違う』という）
必要最小限の複雑さをまたいだ場合、またいだ場合に起こることの片括弧２より、プログラミング上で似ていることは、考えられません。
似ているかどうか考えるためには、必要最小限の複雑さより細かい粒度で議論しなければならないからです。
なお、プログラミングで「似ている」を表現する典型的な方法として、“インターフェイス（明に暗に）”があります。
似ているプログラムを1カ所に書いてパラメタを設け、似ている内の違う部分をパラメタの切替で表すのです。
もちろん、ここで言う“インターフェイス”とは、
- 名前の付いたシグニチャを束ねて名前の付いた明なる“インターフェイス”とする場合
- 名前の付いた束ねられていないシグニチャからなる”インターフェイス”（いわゆるメソッドです）
- 名前の付いていない（典型的にはHTTPのPOSTパラメタの様な）暗なる“インターフェイス”のいずれでもありです。
もしまたいだ場合、この様な（本当に）有用な表現方法を封印してしまうのです。
●その「弊害」からなにが起こるのか？
それぞれの乖離による弊害から、漏れ抜けが起こり、障害（設計の状態）や故障（問題が起きた状態）の要因になると思います（用語は、「ソフトウェア品質知識体系ガイド」オーム社より）。
その1（『コピペ』）では、障害を誘発する原因になります。
コピペした直後にコピペした当人であるなら別ですが、コピペされた複数箇所のプログラムは、同じであるか定かではありません。
その後、保守時などにコピペの一部のみを保守し、他の部分を忘れてしまう可能性は大きいです。
その2（『擬似抽象化』）では、それっこそ各変数の「参照／更新」を悉皆で調査し、人間のパターン認識能力の極限まで発揮して、でも完全には理解できない（保守できない）プログラムになると思います。
その3（『みんな違う』）では、その1と同様に、一部のみを保守し、他の部分を忘れてしまう可能性が出ます。
●まとめ
（それを踏み越えて単純化すると意味が無くなる）必要最小限の複雑さをまたぐことは、公開表現と内部表現の乖離を招き、それにより漏れ抜けを招来する大きな一因になります。
今世紀に入って、主流的な考え方は「業務に即した粒度に、プログラミングを合わせる」事だったと思いますが、それが可能だったのは、そういう合わせ方が可能なら、質的に別物のプログラミング開発が可能になるという将来への希望があったからで、しかしながら新世紀になってから10年以上経っても、それでいいことなど何も無い訳で、もうあきらめるべき時期に来ていると思います。
もちろん、ビジネスの本義は「お金を儲けること」であり、「業務に即した粒度に、プログラミングを合わせる」ことに賛意を示しさえすれば、成果がどうであれかなりのお金をくれる人間が居る内は、それが
「ビジネス的ファクト」だったのも事実です。
しかし、もうそんな人はどこにも居ません。
プログラミングは設計の段階から「必要最小限の複雑さ」を超えないよう、適切な粒度で、きちんと保全していくことこそ今後の「ビジネス的ファクト」だと思います。
まぁ、今回はこんな所です。
●雑感
筆者の住んでいる近所でも、「自転車は車道を走るべき」という指導をつきっきりでやっているところがあります。
自分はドロップハンドルでなくクロスバイクで、しかもレーパンなんかでなく、普通の（ポリエステルの）スラックスで走り回っているせいもあり、大いばりで歩道を走ったりしてもいます。
でも、クロスバイクなので、それなりに車道に出ることもあります。
その経験から思いますに、自転車で車道を走るために必要な資質として、『車の機動』に馴れていることが必要ではないかと考えます。
『車の機動』に関するおれおれ定義ですが、自分が（踏み込んだりブレーキを掛けたり曲がったりして）加速度・減速度を受けている最中に、周りの複数の他車の加速・減速を認知し、安全に対処するとします。
これが必要か否かが車道で走ることと、歩道で走ることの大きな違いだと思います。
この資質がない人（それでも自転車に乗ることはOK）に車道に出ることを言うのは、片落ちだと思います。
なんでこのようなことを言い出したかというと、当記事の太宗である「自転車と」「プログラミングと」の認識の類似とは、これでないかと思ったりしたからです。
でもこれはまた、別の話と言うことで。
●コラムのコメント欄の方針
コメントに対し、当意即妙の回答を、それなりのタイミングでする自信がありません。
ですので、このコラムで、
・わたしは基本的にコメントに答えない
・コメントを書く人は、回答がない前提で議論を進めていただく
とさせていただきます。