最近見えてきた境地の一つなのですが。
すべからく。プログラムには「隙間」が必要です。
より具体的には「少々の変更修正追加」に対して「あぁそれならここに入れればよいですよ」という、なんだか「整理上手な奥様」のような発言がさらりと出来る必要があります。
無理矢理に押し入れに押し込んだりすると後で自重崩壊しますよねぇってのは先日も話をした内容。
そんな感じで「適度な隙間」は、生活をする上でもプログラミングにおいても、とても大切なものである事がわかります。
一方で。全体構造に「隙がある」のは、それは激しく「如何なものか」感が漂うと思われます。
具体的には。
客「こんな機能を追加したいんだけど」
エ「え…あ…はい…(どうしよう(汗))」
とか
客「項目追加をいくつかしたいんだ」
エ「え…あ…はい…(どうしよう(汗))」
とか
客「ちょっと不信なログがあるらしくて。プログラム側でもロギングしてみてくれ」
エ「え…あ…はい…(どうしよう(汗))」
とか
客「セキュリティ的に、こういう懸念が上がっているから対策をしたいのだが」
エ「え…あ…はい…(どうしよう(汗))」
とか。
出来ないならせめて「あらかじめ考察をしておいて、ちゃんとした理由の元に出来ない」とか言えませんと、なにがしか、不信感のようなものが漂いはじめる可能性があります。その対象がせめて「作成したプログラムに対して」であれば、まだよいのですが*1。
「全体的に隙がある」理由をかみ砕きつつ分析をしますと。
概ね大本にあるのは「言われた事を、唯々諾々と、理解もせずに実装をする」か、或いは「全体設計のスキルが低い自分、という状況に対して無知の無知」であるか、のどちらか(或いは両方)。
然る後に、そういう方ほど「とにかく作り込む」。
ちなみに。どんな矛盾したお話であろうともいい返事で快諾したりするので、現場の「エンジニア以外」からのウケは結構良かったりする事も多いですね。途中まで、ですが。
んでまぁ。
そうすると、とりあえず動いているように思われる「水も漏らさぬようなブツ」ができあがるです。
作業としては一段落。
ただまぁ、比較的多くの場合において「当初の仕様から、ほんの少しばかり、わずかながらの、ごく微々たる、或いは軽微な*2修正や追加」という状況/要求が、これは経験上「ほぼ確実に発生する」と言えます。
しかし「水も漏らさぬようなブツ」ですからなまなかな事では「修正も変更も」受け付けません。
とはいえ「出来ません」とも言いにくいものがありまして(画面項目の一つや二つ追加する程度でそこまでの難色示されても困りますしねぇ、発注する側としては)。
現実問題としての「ブツの質」と、違う角度の現実問題としての「受け入れざるを得ない状況」のこの二つが化学反応を起こしますと。
どうしても「想定外を無理矢理乗せる」という手法を経由せざるを得ず、結果、見事な「すぱげっちぃ」ができあがるわけです。
まぁ。そのあたり「柔軟性に欠ける」とか一言で切り捨ててもよいわけなのですが。
かくして、思うわけです。
「隙間があって隙のない設計」が必要だなぁ、と。
もうちょっと言葉を平たくすると「差し込む余地はたくさんあるけれども、全体構造としては油断がない設計」とでも言いましょうか。
そんなものが、多分、必要とされているんじゃないかなぁ、と。
って書くと「すげぇむずかしそう」ですが。
昔から連綿と言われている「真っ当でまっつぐな構造化プログラミングなりオブジェクト指向なり」をちゃんと使えば。
つまり「それらが必要とされている理由を知り」「自らの使うべき道具の長所と短所を把握した上で」「尤も適切な道具を最低限だけ使う」ようにしていれば。
案外に、ちゃんと「隙間があって隙のない」ものができあがるですよ。
って一文で片付けてよいほど簡単ではないかもしれませんが。
