dotkuwaの日記: M1M2VCモデル 1
日記 by
dotkuwa
M1M2VCモデル
この前、OJTの手伝いという事で、サーブレットで
ちょっとしたシステムを作るサポートをしました。
ちょっとしたシステムだったので、ViewModelとか
ややこしい場面には出くわしませんでしたが、
Modelは明らかに(自然に)二分されました。
ここでは、それを「M1M2VCモデル」と称します。
・M1:Beanともいわれる、定義域値域いっぱい
いっぱいに均一で、素直で、テスト容易。
・M2:特に専門的名前の無い、共通モジュールで
要件を満たすためのややこしさを体現する
ロジック。
・V:ブラウザ画面。jQuery、JSONを使いまくり
だが、一度表示した画面を二度目に表示すると
jQueryのReadyが発火せず、画面初期値は
JSPの<%= ... %>タグを多用。
・C:サーブレットといわれる、Get、Postを
受け取り、モデルを使うもの。
となります。
今回の設計書は、昔ながらの画面単位のもの
(V単位)でしたが、OJTの別のチームは、
M1単位で管理しようとしていました。
TDDの変形版とも言えるのかも知れませんが、
「てこの重い方で、軽い方を管理する」様に
見えました。
M1層は(自分の持ち分では)
・頻繁に変わり、
・やってみないと分からず、
・定義域値域いっぱいいっぱいで素直なだけで
直感的に、事前に「判る(文書化可能である)」
訳では全く無く、
結果、
・(末端ユーザーの)要求に比べてずれた内容の
文書が全ての足かせになり、先に進まない。
様でした。
管理の単位を、V単位からM1単位にするのは
どう見ても改悪だと思います。
コボラーとして言うなら (スコア:1)
自分はCOBOL74からコボラーとなったのですが、
その頃は、今回の発言で言う「M1」の部分
(アクセスモジュール)は固定で、
そのアクセスモジュールで出来る事以外
禁止でした。
#ちなみに「V」部分はMEDでした。
ただ、「M1」の部分を固定にするという事は
開発が収束しやすくなるという利点が有り、
コンピュータを動かすのに月千万単位で必要で、
一人当たりメモリk語だった頃には、
たしかに有効でした。
ですので、今日でも、初心者向けに制限の多い環境で
一から学ぶ場合、「M1」部分を固定にする事は
有効かも知れません。
#ただ、それを実世界に持ち込まれると非常に迷惑
#ですが。。。
しかし、開発環境を欲しいだけ複製できる様な
今日、テストが容易な「M1」の部分を可変とし、
他のテスト困難な層の見通しを良くするという
テクは無くてはならないものです。
良さが昔と比べて180度変わったのです。
---------------------
後、話は変わりますが、
・もう、COBOLの事を馬鹿にするのはヘイトスピーチと
して取締る
べきでは無いでしょうか?
今のコボラーには、
・全世界の唯一の仕様言語としてCOBOLを選定し、
自分らはその唯一言語の詮議者に連なるもの
として、莫大な富を得続ける。
と言った、大望を持つものでは決してなく、
ただ単に、
・数年、十数年でフェードアウトしてしまうかも
しれないシステムを守り続けている
人間に過ぎません。
しかも少数です。
COBOLを馬鹿にする事で、彼らを苦しめる事に
何の公益も無いと思います。
自分も、昔からCOBOLをやっていて、悪い所、困る所
は重々承知しています。
しかし、もはやそれを言って何になるのでしょうか?
フェードアウトし切るまでは、必要不可欠な人材の
気持ちを挫いて何がいいのでしょうか?
(面白いのは確かだとは思いますが、これが面白い
唯一の事では無いと思います。)
ですので、COBOLを馬鹿にした事を知り、しかし何も
手立てを講じないプロバイダーも悪意のある共謀者です。
個人を個人で責める事が困難で有るなら、プロバイダー
を責めるべきかと思います。