特定の側のみからの「ベストプラクティス」 ４

別の分野

ドメイン駆動設計をはじめよう　―ソフトウェアの実装と事業戦略を結びつける実践技法　Vlad Khononov　著、増田 亨、綿引 琢磨　訳　O'REILLY Ebook という本*1を読みました。

「区切られた文脈」といった用語が有りましたが、

• なぜ区切られるのか、について（全部では無いにしろ、一部分でも）因果ダイアグラムで説明が付くのでは無いか？
• 同じ原因のセット（似ている原因のセット）だから区切りの同じ側に居る？！

とかといった感想を持ちました。また「文脈の地図」でも、

• なぜこの図なのか？

についての説明に因果ダイアグラムが使えるのでは無いか？との感想を持ちました。

継承がダメで、関数・型は最高？？？

オブジェクト指向の継承はダメで、関数・型は最高だとする関数型設計の本を読みました。

確かに継承は、

• 手段として使う（サブクラス全部に共通の初期化メソッドを置くなど）

分には良くても、「簡単な」記述とかいって、

• 継承を多用し、その機構を誤用にとも言える使い方をし、設計を実現する

風になったらお終いな面は有ります。ただし、
もちろん、お終いのプログラムになる原因は有るはずです、

さて、静的な型も『手段として使う分には良くても、、』うんぬんが成立すると思います。そんなに良いなら静的な型で統一出来そうなものですが、動的な型の言語もかなりの勢力が有ります。

それも又、
統一出来ない原因は有るはずですが、

もし、それら原因が同じだとすると、まさに目くそ鼻くそのワールドです。そして、かなりの確率でそうなると私は考えます。

継承と型・関数の悪さの原因が同じかどうかという観点で物事を考えてみるのはいかがでしょうか？
もしそれが成った暁には、「関数以外不適当とゴリ押しするユニットテスト」という分野の見直しも成就するかも知れません。

結論

これからも『特定の側のみからの「ベストプラクティス」』を無理押しされる事でプログラミングが嫌いになる人は存在し続けることでしょう。

*1:PDF版をKindleのパーソナル・ドキュメントに入れて使っています。

特定の側のみからの「ベストプラクティス」 ３

「関数だ」との主張を好意的に解釈すると

もしかするとですが、

• 「関数」を持ち出した人間は、比喩のつもりだった

のでは無いかと思う様になりました。

数学畑でもソフトウェアシステム畑でも無い人が、です。

それなら、

• 全てを関数として扱う

とかが成立するからです。

不運１

数学では、比喩なんて有りません。比喩的なもっと抽象的な概念は、別の名前を付けるはずです。

そうすると、関数とは、（一貫して）地を這う存在の如く、俯瞰が出来ない存在になります。
曖昧で、厳密さに欠ける、自然言語が、鳥の視点を持つのと対照的です。

不運２

プログラマー（私も含めて）に関数と言えば、defunだとか、型定義だとかで記述されるアレら以外思いつきません。
また、職業人としては、特に、思いつくべきでは有りません。

関数とは、関数名が有って引数が有って、結果が有るアレに限られます。

プログラマーに、「考えるのはお前たちだ」と言っても、何も進みません。

不運３

関数や型は、オブジェクトと同じ欠点を持ちます。継承がダメ（その様な都合の良い共通性も無いし、インターフェースもちっとも不変で無い）なのと同じで、
型もダメ（その様な都合の良い共通性も無いし、インターフェースもちっとも不変で無い）のです。

オブジェクト指向をコケにした勢いで、関数や型を褒めても、全く意味が有りません。欠点を共有している点は（それこそ）不変だからです。

不運４

もちろん、比喩の存在としての関数が存在するならば、その様な不運は一挙解決だったのかも知れませんが、

• 比喩で有っても良いから
• 新しい、素晴らしい
• が全く無かった（10年経っても、20年経っても出てこない）

のが大きいと思います。「比喩の存在としての関数」は、形而上的存在ですら無い（もっと悪い）のだと、強く思います。

結論

もっとも好意的に捉えても、これですから、

これからも『特定の側のみからの「ベストプラクティス」』を無理押しされる事でプログラミングが嫌いになる人は存在し続けることでしょう。

特定の側のみからの「ベストプラクティス」 ２

結局の所、

結局の所、

• 来るべき業務承継に備えて、
• 文書化のコストをかけて置かないと、
• 後で禁止的に高くなる

だけなのかも知れません。

が、

が、その文書化を、

• 全て関数

に出来るかというと、それは正しく、

• 特定の側のみからの「ベストプラクティス」

に過ぎないと思います。

ユークリッド幾何学での曲線（例えば今私も使っているX25519とか）ならそれが言えると思いますし、それがリーマン幾何学になっても同じでしょうけれど、

プログラム（とその設計、その設計の原因、その設計の原因、、、、、）の構造は違うと思います。

全て関数というのは、特定の側のみからの「ベストプラクティス」だと強く思います。

結論

これからも『特定の側のみからの「ベストプラクティス」』を無理押しされる事でプログラミングが嫌いになる人は存在し続けることでしょう。  

特定の側のみからの「ベストプラクティス」 １

どの様な話？

前に「投資を呼ばない形而上の提案を形而下のそれと等価だと言われる　３」で、

上代のCOBOLシステム（汎用機システム）では、

・　新規開発も、保守開発も、運用業務も全て同じ組織で担って

いました。

それをその後、
（大変だけれど大変もうかる）運用業務や、（大変でもうからないけれどしないといけない）保守開発を、別の組織が（その業務の中心人物を中心として）

・　持っていってしまう（スピンオフ？　違う？？）

ことが有りました。

それを考えると、のちの運用組織がDevOpsとか言っているのは、

・　単なる自業自得（いいとこ取り、クリームスキミング）

にしか見えません。スピンオフしたいと言い出したのは運用組織の方で、それでかなり儲けたはずです。調子が悪くなってから、みんなの事を考えようとか言うのは不誠実です。

と書きましたが、運用業務や保守業務で無く、テスト業務も同じだったと思います。

一目千両の大名人（一目見ただけで、問題点を網羅する）の、その業務の中心人物が、全てをやっていた同じ組織から抜け、

• 大変な所（不具合対応）は引き受ける
• プログラマーは、それら大変な部分はしなくていい
• プログラマーの給料は当面そのまま
• （ただし、今後評価の面でプログラマーは低く見られる事になる）

とするとの事で、4番目について知らされていなかった事も有り、特にプログラマー側も気にしませんでした。

確かに、

確かに、「全て同じ組織で担う」上代の開発分担では、当然因果推論能力も、体力も必要で、市役所に楽にうかる様な人間を、毎年10人単位で集め続けなければならず、

その様な事をし続ける事は出来なかったので、その様なスピンオフの申し出は、渡りに船だったと思います。

その当時としての「ベストプラクティス」

これが時代の潮流として成立したのは、ひとえに、

• その業務の中心人物が、
• 大変な所（不具合対応）は引き受ける

とした為だったとしか思えません。

しかし、その様な人物もよる年波には勝てませんし、当然命脈が尽きる日も来ます。

さらに「業務の中心人物」は、

• かなり勝手な事を、やった事の文書化もせずに居るだけなので、
• 後輩をキャンセルする性質が有り、
• 後継を作れない

特徴が有ります。時代の徒花にしかなれない訳です。

残されたスピンオフ側のみからの「ベストプラクティス」

残されたスピンオフ側のみからの「ベストプラクティス」としては、

• プログラマーに
• 一目千両の（一目見ただけで、問題点を網羅する）
• 資料（どの様な物か不明で、誰も見た事が無い、作り方の糸口すら無い）を
• 無償で作らせる

となるとは思いますが、それは、

• 特定の側のみからの「ベストプラクティス」

に過ぎないと思いますし、絶対に実現しないと思います。

まだ、プログラマーに設計の単価を渡して、結果たるプログラムの原因を提示してもらう方が、幾ばくかでも現実味が有ると思います。

結論

これからも『特定の側のみからの「ベストプラクティス」』を無理押しされる事でプログラミングが嫌いになる人は存在し続けることでしょう。