デスマ
デスマの正式な定義がどのようなものか分かりませんがここでは
状態をデスマと呼ぶことにしたいと思います。
果てしなくやることがあって終わりが見えない。
作業を1つ終えると予想してなかった別の作業が増え
作業量が予測できない。
デスマは基本的に先を急ぐあまり今本当は
やらなければいけなかったことを端折り、
結局後で高いつけを払うことのスパイラルでは
ないでしょうか。
本当にやらなければならなかったこととは、
正しい設計・テストであり、自動テストに守られた
デグレし難い環境でしょう。
内部設計からやり直せるなら、デスマは回避できると思います。
http://d.hatena.ne.jp/higayasuo/20040607#1086565824
の事件がまさしく結合テストでぼろぼろ、
どうしようもなくて内部設計からやり直したケースです。
フレームワークは何を使っていても良いと思います。
一番大事なのは作業量を正確に見積もることです。
そして作業を終えたら確実に終わりに近づくようにすることです。
作業量を正確に見積もるためには、業務ロジックをこれ以上分解できない
アトミックな物になるまでばらします。
確実に終わりに近づくようにするために自動テストをきちんと
おこないます。
仕様変更もどうせあるでしょうから、自分の身を守るために。
着実に終わりに一歩一歩近づいているんだという達成感が
デスマの一番の特効薬です。
UIから業務ロジックは分離してください。
業務ロジックをアトミックになるまでばらしたら、
インターフェースに割り当てます。
インターフェースと実装を分離するのは、いつの時代でも大事です。
実装が追いつかなくてもお互いに作業を進められますし、
モックを使って簡単にテストできるようになります。
クラス間の依存性の解決は、直接ハードコーディングしても
良いでしょう。ただし、setterメソッドを用意して
モックと簡単に交換できるようにします。
インスタンス変数の型ももちろんインターフェースです。
業務ロジックは、ステートレスが良いでしょう。
ステートフルな設計は難しくデスマな状態のプロジェクトでできるとは
思えません。
業務ロジックのクラスからデータにアクセスするロジックは分離します。
データにアクセスするロジックはDaoにまとめこれもインターフェースと
実装を分離します。
Daoのテストは自動テストでなくてもとりあえず良いと思います。
これらのことはダイコンを使わなくても十分おこなえます。
結合テストからデスマにアサインされやり直しもできない場合は...
どうしようもない気がします。(^^;
