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

2018年4月12日木曜日

MVVM覚える位なら、Unityやった方がイイ!

MVVMデザインパターンとは何か?

 簡単に言うと、WPFやXamarinの為にあると言える。

 WPF:絶えるとと思ったが、意外と耐えた。
     XAMLなる、XMLみたいなデザインで画面をデザイン出来る為、WindowsForms
    であったような、コントロールで実現できないデザインはオーバーライドで
    ゴリゴリしなくて良くほぼ自由自在にデザイン出来る。

  WPFが流行るに流行れないのは、やはり、いつの間にか、MVVMデザインパターンでプログラミングするスタイルが定着した事だと思う。

  MVVMは、物凄く大規模で、継続性があるシステムだと一定の効率効果は得られるが、小規模、モックアップ、事業として成立が難しい案件かも知れない場合、これに見合う開発工数では無くなる点だ。

  行ってみたら、普通にコーディングしたら、一行で済むようなコードを、わざわざ、モデル、ビューモデル、ビュー(XAML)の三本柱を連携するようにコーディングして行かなくてはならない。

 
Label.Text = "test";

Windows.Formsだとフォームにラベルコントロールを一つ置いて、文字を出す場合、これだけで済むのだが、WPFの場合は、XAMLで設定したコントロールに、どのモデルの変数と割り当てるかを細かく振る舞いを書いて、モデルで変数を用意して、ビューモデルでモデルの変数とビューの橋渡しを行えるようにコードを書く。


Xamarinとは何か?

 昨今流行っているクロスプラットフォームである。

何が出来るかと言うと、C#一本で、Androidアプリ、iPhoneアプリ、Windowsアプリの全てが開発出来てしまう。

欠点: 各方面でC#で開発と言われてはいるものの、実は、Android.Java
    やiPhone.Objective-Cのクラス等を、そのままC#にしただけ。

    つまり、Android,iPhoneの開発をそれぞれの言語でやった人では無いと、
    これの意味は分かりにくいが、そういう事なのだ。

    だから、Windows.Formsみたいな、LoadやInitialで始まるなんてあり得ない。

    iPhoneのViewDidLoad等、それぞれのOS専用のライフサイクルはそのまま
    引き継いでおり、Windowsの開発スタイル一本で開発は出来ないのだ。
    (UWPがそれを目指しているが・・・ビューにWebのようなレスポンシブル
     デザインを求めており・・・アプリで開発するメリットが・・・無い)


そこでUnity(ユニティ)!!

 Unityは、ゲームエンジン・・・だから、業務システムエンジニアには興味関心の対象とならないかもしれないが、使ってみると凄いことが分かる!

 実質C#そのまんまで、Androidも、iPhone(iOS)もWindowsアプリも作れてしまう!!!

 Xamarinのように、それぞれのデバイス毎に必要なお作法も、実質無い!

 この素敵な環境を業務でも使えるのではないかと思う。

 業務アプリではしばしば、デザインについて、妥協する事も多い。
 
 時には、Direct-Xを使ってアニメーション処理したり、メモリ内で、プライマリサーフェス、セカンダリーサーフェス使って、アニメーションを転送したり・・・座標でボタンの位置やったり、業務アプリの工数に求められていない開発工数が発生する場合もあるのだけれども・・・

 だから、WEBでやっていると思うのだけれども・・・

 Unityだと、当たり判定も全て配置したコントロール(アセット)のプロパティで持っているから、これがそのまま、Clickイベントのように使えたり・・・

 それでいて、出力するデバイスを選んでコンパイルすれば、APKでもEXEでも、各OSに必要なアプリを一発で作成してくれる!!!

 ゲームエンジニアにとっては、業務アプリ開発でも活躍出来る可能性が広がったといえるのでは!?

 データベースを内包する場合は、それぞれのデバイス特性を知っていないと難しいため、WEB-APIでやる事の方が多いのだろうか!?

 ああれ、・・・結局WEBシステムが必要!?

 WEBは維持が大変で、セキュリティは大手でも個人情報流出やらかす位、守れないに等しい産物。
 
 WEBを使わないシステムを考えているエンジニアは昨今多いのでは?

 
 まぁ、せめて、WPFのMVVMデザインパターンをやる位なら、Unityを試しにやってみるのが良いと思う。

 新しい操作性も提案可能で、Xamarin程学習コストもかからないと思う。

 



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位の言語へ・・・!!



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

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

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


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


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

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

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