ダイコン時代の設計手法-その2

これは、私のことではありません。友達の話です。


時は2002年。
まだ、ダイコンなんて言葉はなかった頃です。
事件は突然起こりました。

めしどこか　たのむ

懸念だった某プロジェクトがいったんリセットされた。

おまえいって立て直してこい。

失敗は許されません。
品質はもちろんのこと、納期についても社内外から厳しいチェックが
はいります。
人数は月50人を超えます。開発に参加している会社も複数あります。
それなりの規模で、すべてに目を通すことなど
不可能です。


期間を短縮するために、画面チームと業務ロジックチームに分けました。
パラレルで開発できるようにするためです。
その当時は、1社(チーム)に画面も業務ロジックも任せるのが普通だったのですが、
1つ勝負に出たのです。


業務ロジックチームの実装が終わらなくても、画面チームが開発できるように
するために業務ロジックは、インターフェースに切り出すことにしました。
アプリケーションの初期化時にインターフェースに応じた実装クラスを
リポジトリに登録し、画面のクラスはサブミット時に
インターフェースのクラスをキーにして実装クラスのインスタンスを
取り出して使います。Picoに似たかんじですが、DIの考え方がないので、
サービスから他のサービスを必要とするときは、リポジトリから取り出して
使います。


最も重要な業務ロジックの設計ですが、短期間で精度が高く人の能力に
依存せずに行う必要がありました。
そこで私は、簡単な指針を立ててそれに従ってやってもらうことにしました。

• データにアクセスするロジックとそうでないロジックを明確に分離する。
• ロジックは状態を持たない。
• 1つのロジックで複数のことを行わない。
• 同じロジックを複数に分散させない。
• データにアクセスするロジックも含めてすべてのロジックは、JUnitでテストする。

たったこれだけでしたが、このプロジェクトは無事カットオーバーしました。
データにアクセスするロジックのテストは、S2UnitのExcelのかわりにXMLを
使うようなかんじです。


それから2年。
私の友達はつぶやきました。

何か合コン誘われたから行ってくるわ