MVVMは、古いプログラマーにとって非常に脅威。 MVVM to attention to older programer...

MVVMは、古いプログラマーにとって非常に脅威。　MVVM to attention to older programer...

何度かMVVMパターンについて取り上げているけれど、改めて、MVVMパターンについて勝手に議論。

古いプログラマーにとって脅威と思うのは、そもそももう設計すら行うことが出来ず、ただの要件定義するだけの人に成り下がってしまうから。

要件定義は・・・実際のところ、覆される事が殆どで役に立たず、
どちらかと言うと、ヒアリングしてプロトタイプ見せて、が出来るエンジニアが良いの
だけれども、日本のエンジニアは、プログラムすら組めない人が多いから、大体の要件定義は、ゼロになるレベルで覆される。

MVVMパターンはSEも知っておくべき

最近のシステムエンジニアとプログラマーの間では、大きなギャップがあると考える。

それは、今みたいにバリデーションのフレームワークやルールが無く、プロジェクト毎にシステムエンジニアによる属人的な考え方で通用していたからだ。
さらに、MVC（モデル、ビュー、コントローラー）のような考えで作られることも無く、Ruby on Railsや、他の言語にあるLINQのようなものも無かったので、とにかく、プログラムの経験も無いシステムエンジニアによる、自由な仕様でも、賛否は少々あるものの大体通用出来ていた。

昨今、急激な進化なのか、ただのシェア争いに巻き込まれているだけなので、物凄く状況は進化変わった。

既存の古い資産を何かする為の設計書は、誰でも書けばそれも一つの有り様だと納得は行くのだけれども、MVCやMVVMパターンだと、それはいくら何でも変じゃない？と思う物が多い。

それは、それぞれの思想モデルを全く意識せずに書かれてしまうからだ。
プログラマーからみれば、タダのやりたい事を書いただけのようなリストに見えてしまうのだ。

MVCやMVVMを意識して設計書が書かれていれば、同じ入力ルールー等は別途そのルールの設計書があれば良いのだけれども、そもそもMVVMを知らないエンジニアにとって、それのメリット、デメリットすら分からずに書く為、プログラマーは予定していた作業工数とは違う作業が発生する事に気がつく。

ビューモデルの共通性を整理する作業。

今、システムエンジニアやプログラマーにとって、大きく４つの世代があると思う

　１．MVVMパターンを知っている世代。

　２．MVVMパターンの名前すら知らない世代。

　３．MVVMパターンの名称だけ知っている世代。

　４．MVVMパターン実践は無いけれど、個人または、ごく小規模で試した事がある世代

１．MVVMパターンを知っている世代。

　MVVM信者の場合

　　メリット
　　　大きなプロジェクト、又は、継続して膨らんで行く筈のプロジェクトな場合、
　　　最初の苦労はあるもののこのパターンを選んだ事に後から凄く恩恵を受けプロ
　　　ジェクトの成功を感じる事となる。

　　デメリット
　　　どんな開発にもMVVMを適用しようとする。
　　　継続されるプロジェクトでは無い場合、やたら無駄な工数が発生し、依頼者側と
　　　の予算でかなりの亀裂を生じさせ、プロジェクト自体が成立しない可能性が..
　　　
　　　が、信者な為、選択肢が無い為、後悔は生じない。


　MVVM信者ではない場合

　　メリット
　　　基本的に信者とメリットは同じなのだけれども、信者ではない為迷いが生じる。
　　　このプロジェクトは、今後も継続しうるプロジェクトで、その規模でデザイン
　　　パターンを選択する程のものなのだろうかと。

　　デメリット
　　　やってみたものの、あまり必要とされなかったシステムだった場合には、信者では
　　　ない為、後悔が生じる。
 　　  自分がやった為に、謎な程予算がかかってしまった事に。
　　　

２．MVVMパターンの名前すら知らない世代。

　　メリット
　　　プロジェクトは単発で終わったり、継続されない数の方が実質は多いので予算が
　　　綺麗さっぱり単発分だけになる。

　　　また、どっち派のエンジニアにとってもやりやすいが、MVVM信者がいた場合、
　　　予算よりも職人肌的な所に重きを置くため、ちょっと ウザイ感じの軋轢が生じる。

　　　が、彼らは彼らで日々新しいものをやっていかないと未来が閉じられるかも知れ
　　　ない世界なので、それも一つの価値だと頷いてみせて、スピード、コスト重視で
         ある事を納得してもらう事が必要。

　　デメリット
　　　大きなプロジェクトで存在していた場合、いつも通りの単発で終わる工数しか
      　組まない為、小さなプロジェクトで予算通りでも、大きなプロジェクトでは
         異様に高い予算となってしまう。

　　　例えば、Windowsアプリ、Web、Android、iPhoneと横展開していく事も今後予想
　　　される場合には、それぞれで、ゼロから作るような工数を想定してしまい、倍々に
         予算が膨らんでしまう。

　　　 また、リリースサイクルも非常に遅くなる。

３．MVVMパターンの名称だけ知っている世代。

　　基本的に、メリット、デメリットは同じだが、まだ、ピュアな為、教えてあげると
      選択肢に組み込まれる可能性がある。

４．MVVMパターン実践は無いけれど、個人または、ごく小規模で試した
　　事がある世代

　　メリット

　　　小規模でしか試していない為、小規模には向かない事を重々承知している為、
    　  おおよそ上手くどっちが良いか判断してくれる。

　　デメリット

　　　小規模でしか経験をしていない為、コーディング量のボリューム増加や使用する
　　　フレームや言語によっては、作り方も全然異なる為、プログラマーサイドからは
　　　常に妥協を提案するやりとりが発生してしまう。

　　　その妥協で救わる場合も多いとシステムエンジニア側もある程度は分かっている為
　　　規則じゃ無い場合には、メリットになる。
   　　

勝手にまとめと感想

　　理想は、取り敢えず雑に作って、当たればMVVMデザインパターンで作り直せる
　   事が出来る環境なんじゃないかなと・・・

　

　　当たるか当たらないかが分からないから、予算管理をする側にとっては、常にその時
　　一番安いコストを選択するのが、日本のシステム何だと思うけれど。

　　ただ、これらのMVPや、MVVMや、MVW的なデザインパターンを選ぶデメリットだけ
　　思う所があるのは、最近は、フレームワーク自体が物凄いシェア争いの渦中にあり、
　　そのやり方が古くなったり、例えば根本的に変えられてしまった場合には、
　　色々なデザインパターンのシステムが増え続け、コストの関係でシステム維新が行
　　えない場合には、言語がトレンドでも、COBOL言語のような運命になりかねないリス
　　クを抱えてしまうのではと考えてしまう。

　　まだ、コンピューターシステムが浸透して、そんなに世代交代が起きていない
　　ので、今後世代交代や色々な世代が出てくることで、折角オープンな世界で
　　コストを削減できても、後からそれが分かっているエンジニアを確保するのが
      難しくなることに気がつくのかもしれない。