WPF開発が失敗する元凶となっているMVVM開発モデルを、採用しようとする開発者の言い分は３つに分かれる。
① MVVMで実装しないと画面間の連携ができない。
② MVVMで実装しないと単体テストでソースコードのカバレッジ100%を達成できない。
③ MVVMを採用しないWPF開発はレベルが低い。
WPFをMVVM開発モデルで開発しないなら、他にどの開発モデルがあるのか？
WPF開発で失敗しないのはMMCSVM開発モデルのみ
①について
画面間の連携には INotifyPropertyChanged を適用した ViewModel を実装する必要があるが、INotifyPropertyChanged が MVVM の機能だと思い込み、ViewModel も INotifyPropertyChanged も、WPF の XAML Binding に対応した WPF の基本機能の１つでしかないことを知らないパターンだ。
②について
MSTestやNUnitで実装したユニットテストのソースコードカバレッジを、OpenCoverなどで測定する際、カバレッジ100%を目指す医療系システム開発の現場などで良く聞かれる。
コードビハインド上のソースコードは、MSTestやNUnitで網羅しずらい為、コードビハインドにソースコードは書かず、ICommandを介したメソッドにイベント処理を全て記述し、MSTest/NUnitのユニットテストからそのイベントをキックすることで、OpenCoverで測定したコードカバレッジを100%にしようとするが、XAML上のソースコードはカバレッジを測定できない為、カバレッジ測定対象外とされ、ICommand を介したメソッドでは実現できないUI処理は結局、コードビハインドに実装され、そのコードビハインド上に書いたソースコードはカバレッジ測定対象外とされる。
ICommand もMVVMの機能ではなく、WPF の基本機能の１つでしかないことも知らない。
最初は、コードビハインドでイベント処理を行い、イベント処理内のビジネスロジックを可能な限り共通Classに外出しし、共通Classのコードカバレッジのみ100%を達成することを目標としていれば、工数が肥大化することは無い。
MVVMを採用することありきで開発をスタートし、工数が肥大化し首が回らくなってから、一部機能でMVVMを諦めても、工数が肥大化した後なので工数が残って無く、リカバリー出来ないということが起こる。
開発に失敗したリーダーは、「同じ状況なら誰でも失敗する。自分が悪かった訳じゃない。」と言い張るが、各ステークホルダーと交渉する能力を、リーダーが持っていなかったのが原因だ。
中身の伴わない上辺だけの「ソースコードカバレッジ100%」を達成する為に極端な工数をかけると、見積もりの破綻、開発プロジェクトの中止が発生する。
経験の浅い開発者は色んな機能を使おうとするが、経験豊富な開発者は筋の良い機能だけを使おうとする。INotifyPropertyChanged の筋は良いが、ICommand の筋は良くない。
WPF開発の現場に、経験豊富な日本人の開発者は居ない為、外国人が公開しているWPF開発ノウハウを事前にリサーチする必要がある。無能なリーダーはこの事前調査もやろうとしない。
XAMLのソースコード
コードビハインドのソースコード
③について
経験が浅い開発者は、インターネット上の情報を検証せず、「WPF開発プロジェクトでMVVMを採用するのは普通だ」と言い張るが、こういう事を安易に言う人物は、その人自身のレベルが低いと見なし、検証結果を含めた見積書の提出を求めた方が良い。
WPF開発 記事一覧
コメント