スポンサーリンク
ロフトネットストア
スポンサーリンク
キングソフトWPS Office 2 for Windows

WPF開発プロジェクトが失敗する元凶となっているMVVM

.NET CoreWPFソフトウェア開発契約マネジメントリーダーシップ開発方式

WPF開発が失敗する元凶となっているMVVM開発モデルを、採用しようとする開発者の言い分は3つに分かれる。
① MVVMで実装しないと画面間の連携ができない。
② MVVMで実装しないと単体テストでソースコードのカバレッジ100%を達成できない。
③ MVVMを採用しないWPF開発はレベルが低い。

WPFをMVVM開発モデルで開発しないなら、他にどの開発モデルがあるのか?
WPF開発で失敗しないのはMMCSVM開発モデルのみ

①について

画面間の連携には INotifyPropertyChanged を適用した ViewModel を実装する必要があるが、INotifyPropertyChanged が MVVM の機能だと思い込み、ViewModel も INotifyPropertyChanged も、WPF の XAML Binding に対応した WPF の基本機能の1つでしかないことを知らないパターンだ。

②について

MSTestやNUnitで実装したユニットテストのソースコードカバレッジを、OpenCoverなどで測定する際、カバレッジ100%を目指す医療系システム開発の現場などで良く聞かれる。
コードビハインド上のソースコードは、MSTestやNUnitで網羅しずらい為、コードビハインドにソースコードは書かず、ICommandを介したメソッドにイベント処理を全て記述し、MSTest/NUnitのユニットテストからそのイベントをキックすることで、OpenCoverで測定したコードカバレッジを100%にしようとするが、XAML上のソースコードはカバレッジを測定できない為、カバレッジ測定対象外とされ、ICommand を介したメソッドでは実現できないUI処理は結局、コードビハインドに実装され、そのコードビハインド上に書いたソースコードはカバレッジ測定対象外とされる。
ICommand もMVVMの機能ではなく、WPF の基本機能の1つでしかないことも知らない。

最初は、コードビハインドでイベント処理を行い、イベント処理内のビジネスロジックを可能な限り共通Classに外出しし、共通Classのコードカバレッジのみ100%を達成することを目標としていれば、工数が肥大化することは無い。

MVVMを採用することありきで開発をスタートし、工数が肥大化し首が回らくなってから、一部機能でMVVMを諦めても、工数が肥大化した後なので工数が残って無く、リカバリー出来ないということが起こる。
開発に失敗したリーダーは、「同じ状況なら誰でも失敗する。自分が悪かった訳じゃない。」と言い張るが、各ステークホルダーと交渉する能力を、リーダーが持っていなかったのが原因だ。

中身の伴わない上辺だけの「ソースコードカバレッジ100%」を達成する為に極端な工数をかけると、見積もりの破綻、開発プロジェクトの中止が発生する。

経験の浅い開発者は色んな機能を使おうとするが、経験豊富な開発者は筋の良い機能だけを使おうとする。INotifyPropertyChanged の筋は良いが、ICommand の筋は良くない。
WPF開発の現場に、経験豊富な日本人の開発者は居ない為、外国人が公開しているWPF開発ノウハウを事前にリサーチする必要がある。無能なリーダーはこの事前調査もやろうとしない。

XAMLのソースコード

コードビハインドのソースコード

③について

経験が浅い開発者は、インターネット上の情報を検証せず、「WPF開発プロジェクトでMVVMを採用するのは普通だ」と言い張るが、こういう事を安易に言う人物は、その人自身のレベルが低いと見なし、検証結果を含めた見積書の提出を求めた方が良い。

WPF開発 記事一覧

WPF

コメント

スポンサーリンク
Thinkfree office NEO
スポンサーリンク
セシール - 3D-BRA(スリーディーブラ)
タイトルとURLをコピーしました