ラベル MVVM の投稿を表示しています。 すべての投稿を表示
ラベル MVVM の投稿を表示しています。 すべての投稿を表示

2017年11月18日土曜日

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

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


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

 1.MVVMパターンを知っている世代。
 2.MVVMパターンの名前すら知らない世代。
 3.MVVMパターンの名称だけ知っている世代。
 4.MVVMパターン実践は無いけれど、個人または、ごく小規模で試した事がある世代


1.MVVMパターンを知っている世代。


 MVVM信者の場合

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

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


 MVVM信者ではない場合

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

勝手にまとめと感想

  理想は、取り敢えず雑に作って、当たればMVVMデザインパターンで作り直せる
    事が出来る環境なんじゃないかなと・・・
 
  当たるか当たらないかが分からないから、予算管理をする側にとっては、常にその時
  一番安いコストを選択するのが、日本のシステム何だと思うけれど。

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

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

   

2017年6月16日金曜日

MVVMパターンのメリットがさっぱりわからない・・

MVVMパターンのメリットがさっぱりわからない・・


最近は、WindowsFormsでは無く、WPFで開発をするみたいだけれども・・・


MVVMパターンで開発が主流になってきているみたい。


MVCみたいなやつの、アプリ版みたいな感じなんだけれども・・・


・・・が、ここまでするメリットがさっぱり分からない。


XAML側のDataBindingの指定で、直接コードの値がバインドされるのは面白いけれど・・
だからなに?って感じ。

コントロールの間にデータ中継される要素が増えて、ただ複雑になって、コード量が増えるだけなんでは?

そして、日本の現場で、実際に、デザイナーと、コーダーが分かれて作業されるなんて日が実際に来るのだろうか・・・

MVCですら、実際には、デザイナーと、コーダーが分かれて作業しているなんてみ見たことが無く、実際には、デザインとコーダーが合体している。

デザイナーから、謎な巨大なイラストレーターのAIファイルを渡されるだけで・・
実際の画像加工もコーダーの人がやっているケースが殆どでは・・!?

が、これが、今の主流なのか・・・

自分は、現場が喜ぶ結果が出来たら、あまり過程にはこだわらない。
今までと同じ表現で良いのに、複雑なプロセスを踏まなきゃいけないなんて・・・

これは、技術の進歩何だろうか??


何となく、JAVAが人気な理由が分かってきた。
JAVAは、コーディングスタイル自体は大きく変わっておらず、コード量は多い物の、古いエンジニアも現役で戦っていけるくらい、成熟している。

・・・が、Microsoft系の言語は、.NET Frameworkになってから、コロコロコーディングスタイルが変わって、もはや、どれが標準なのか、さっぱりぱりぱりだ。

結局のところ・・・

すっごく揉めて、こだわって作っても、1年先にはまた新しい手法が登場して、
その時それに拘っているのは、ただのエンジニアの自己満足だと思うのだけれども。。。


技術の進歩は、段々成熟して殆ど変わらないから、自分は、実際に現場の業務効率化で役に立つものだけを作っていたい。。。


言語・・・Python(パイソン)に乗り換えようかな・・・
Winアプリも、Webアプリも、AI学習も人工知能も何でもありで、Googleも使っている言語のようだし・・・




因みに、Pythonは、TIOBEではかなり順位をあげて、一気に、4位の言語へ・・・!!



最近、なんか、言語が多様化しすぎて意味不明な状態だから、業務を効率化させるためのプロデューサーみたいな感じな事が出来ないか模索中。

今は、殆ど自営状態で、営業も、エンジニアも、経理も全部ひとり状態でしんどい(^^;
このまま続けて、黒字になるのか、赤字になるのか等、不安すら持っていられない程、激務な状態だし・・・

顧客がもっと取れれば良いのだけれども、自分で営業してみて、日本の企業が、システムに対する価値(相場)が余りにも低すぎてビックリだ・・・


日本の場合、大きなプロジェクトは、大手ゼネコンの餌にありついているだけみたいな構図で、中の人で出来ない難しいことだけ作らされて、後はソース渡して、はい、さようなら みたいなのが起きることがまた目に見えているから、どうしてもやりたくなくて・・・・


やっぱり、どっかのメーカーな会社員になれないか、検討中。。。

業務効率化や自動化がやっぱり面白くて好きだからそういうのやりたいなぁ・・。
お金のある会社で・・(^^;

お金のない会社ではもうやりたくないなぁ(;´・ω・) ジリ貧になる