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を知らないエンジニアにとって、それのメリット、デメリットすら分からずに書く為、プログラマーは予定していた作業工数とは違う作業が発生する事に気がつく。 ビューモデルの共通性を整理する作業。 今