こんにちは、赤坂です。
Susumu YAMAZAKI <yamazaki@....jp> san wrote:
> 恐らくこの問題に関してもいわゆる 1:9 の法則があって、ほとんどのクラス
> は責務の分析をしっかりやらずにプログラミングしてもあまり問題がないが、
> 一部のクラスは分析をしっかりやる必要があり、そのバランスをうまく調整す
> る必要があるという事ではないでしょうか。
すみません、素朴な疑問なのですが、
1:9の法則は初耳なのですが、20-80の法則とは異なるものでしょうか？
> 僕が問題を感じるのは、責務を変更するようなリファクタリングは比較的コス
> トが高く、責務を分析すべき所でしっかり分析しないと後で痛い目にあう場合
> があるということです。
これはきっと、おっしゃる通りだと思います。
> 実際に経験した例では、一連の処理を段階ごとに分解(A->B->C->...)し、それ
> ぞれの段階の中間結果オブジェクトを渡す設計にしたのですが、各段階で行う
> 処理の責務を変更せざるを得なくなった時(特に中間結果のインターフェース
> を変えざるを得なくなった時)、各段階ごとに作成した膨大なテストケースを
> 修正する必要に迫られて困った事があります。
コードの修正については、ある程度覚悟が出来るものですが、
影響するテストケースの修正についてはガックリしますよね。
＃ やっぱり単体テストに外部パッケージへの依存を持たせてはいけないのでしょうか？
> いつ詳細な分析を必要とするかという問題は、経験に依って判断する要素が多
> いようで、デザインパターンとまでは行かなくてもリファクタリングで述べら
> れいる「不吉な臭い」のような形で良いのでカタログ化できないものかと個人
> 的に思います。
いつ分析すべきか、については難しいですよね。
XPでは大まかなアーキテクチャにメンバーの合意が得られてから、ペアプロを行
うものだと理解していましたが、それは間違ってますでしょうか？
後は、実現するタスクカードごとに合意の取れたアーキテクチャへの影響(変更
しなければならない部分)を見て、分析したほうが良いかどうか判断するのでしょ
うかね。
ではでは。
--
赤坂 英彦 (Hidehiko AKASAKA)
akasaka.h@....com