DIコンテナとくーすとマジカ

work

DIコンテナは仕様（インターフェース）と実装を分離した開発のためのツール。
仕様はWhatで、実装はHow.
仕様と実装を分離した開発にどういうメリットがあるんやろ？

  • テストをしやすくなる
  • レイヤー別の並行開発をしやすくなる

（レイヤーにはプレゼン層、コントロール層、サービス層、DAO層、永続化層があります）

  • なんでテストがしやすくなるんやろ？

あるコンポーネントを使う利用者はそのコンポーネントの仕様に沿って利用する。利用者は仕様どおりに動作することを望んでるだけで、その実装がどうなっているかは知らなくてもよい。（知らなくても期待どおりに動作するから別に知る必要もない）ということは仕様どおりに動作する実装さえあればよい。DIコンテナは実装を組替えることができる。仕様どおりに動作するテスト用のモックと本当の実装をカンタンに組替えることができる。

  • なんでレイヤー別の並行開発がしやすくなるんやろ？

テストしやすくなることと同じで、レイヤー間のやりとりもコンポーネントの仕様に沿う。仕様どおりに動作すればよいので、本当の実装ができてなくても仕様どおりに動作するモックさえあればレイヤー内で開発は進めることができる。


でもコンポーネントの仕様ってどうやって決めればええか迷うわ。。
そこで、仕様と実装を分離した開発のための手法である「くーす」が指針となる。くーすは仕様の事前条件・事後条件を明確にするための考え方・ドキュメントを提示している。また、レイヤー別の役割を明確にしている。言い方を変えると「縛り」を与えているので、開発者はそれに沿って迷いを最大限減らした状態で設計することができる。「縛り」があることでバグの原因を突き止めやすい利点もある。


確かに仕様どおりに実装できるかもしれへんけど、そもそも正しい仕様を決めることが大変やん。ユーザーが決めてくれるわけちゃうし。せっかく決めた仕様も仕様変更されたらガタガタなるし。
そこで、要件定義の精度をあげる業務分析ツールである「マジカ」が指針となる。マジカはユーザー自身に、「楽しく」業務分析してもらうために工夫されたツール。現実的にSEがやる業務分析はだいたい間違っている。ユーザーから出てくる言葉だけが本当の事実であり仕様。SEが想像で業務を分析してはいけない。




・・・うーん、いまいちやなあ。分かってるつもりでも人にうまく伝えることができなければほんまに分かってるとはいえへんなあ。。
だれかツッコミたのむ