山崎＠東工大です。
> > 恐らくこの問題に関してもいわゆる 1:9 の法則があって、ほとんどのクラス
> > は責務の分析をしっかりやらずにプログラミングしてもあまり問題がないが、
> > 一部のクラスは分析をしっかりやる必要があり、そのバランスをうまく調整す
> > る必要があるという事ではないでしょうか。
>
> すみません、素朴な疑問なのですが、
> 1:9の法則は初耳なのですが、20-80の法則とは異なるものでしょうか？
同じ物です。どちらも聞くので少し悩んだのですが、今回の場合比率がどちら
かと言えば 1:9 の方が近いような気がしたので、1:9 と書いておきました。
20-80 の法則と言った方が一般的だったかもしれません。
> > 実際に経験した例では、一連の処理を段階ごとに分解(A->B->C->...)し、それ
> > ぞれの段階の中間結果オブジェクトを渡す設計にしたのですが、各段階で行う
> > 処理の責務を変更せざるを得なくなった時(特に中間結果のインターフェース
> > を変えざるを得なくなった時)、各段階ごとに作成した膨大なテストケースを
> > 修正する必要に迫られて困った事があります。
>
> コードの修正については、ある程度覚悟が出来るものですが、
> 影響するテストケースの修正についてはガックリしますよね。
> ＃ やっぱり単体テストに外部パッケージへの依存を持たせてはいけないのでしょうか？
理想的には依存がない方が良いでしょう。しかし今回の場合、中間結果オブジェ
クトに情報を格納するので、必然的にテストケースが中間結果オブジェクトに
依存します。このような場合にどのようにコード／テストケースの設計をする
のが理想的なのか、皆さんにご意見を伺いたいです。
> > いつ詳細な分析を必要とするかという問題は、経験に依って判断する要素が多
> > いようで、デザインパターンとまでは行かなくてもリファクタリングで述べら
> > れいる「不吉な臭い」のような形で良いのでカタログ化できないものかと個人
> > 的に思います。
>
> いつ分析すべきか、については難しいですよね。
> XPでは大まかなアーキテクチャにメンバーの合意が得られてから、ペアプロを行
> うものだと理解していましたが、それは間違ってますでしょうか？
大まかなアーキテクチャを決定するのは(ペア)プログラミング以前であるべき
だというのは、その通りだと思います。一度学生達に分散ドローツールをXPも
どきで開発してもらったのですが、途中でアーキテクチャの変更を迫られ、非
常にコストがかかったという事がありました。その教訓から、大まかなアーキ
テクチャに関しては詳細な分析が必要だというのは賛成です。
僕が問題にしているのはその後の話です。先程の一連の処理を分割した例でも
大まかなアーキテクチャに関してはプログラミング以前に決定していたわけな
のですが、開発中に責務の分割を見直す必要がある例を発見したので修正が必
要になりました。この時の反省点として、要求仕様が変化した訳ではないので
責務の分析をもっとしっかり行っていれば、修正を回避する事が出来たのでは
ないかと考えた次第です。
> 後は、実現するタスクカードごとに合意の取れたアーキテクチャへの影響(変更
> しなければならない部分)を見て、分析したほうが良いかどうか判断するのでしょ
> うかね。
もう少し先程の例の問題点を分析しますと、ストーリーをタスクに分割し、タ
スクカードを見ながら開発を進めて行った際に、タスクカード全体を見渡さず
に一枚一枚のタスクカードの実装に専念してしまったために局所解に陥ってし
まったのが、修正が必要になった一番大きな理由です。
しかし、タスクカードが非常に多かったため、開発前の段階でアーキテクチャ
への影響をきちんと分析しないうちに見切り発車で実装を進めてしまったのが
後で問題になりました。
最初の時点でこの部分の分析を深く行う必要があるという認識があれば問題を
回避できたのですが、その判断を助ける「前兆現象」「不吉な臭い」を捉える
方法が整理されていれば、経験の浅い人でも正しい判断を下せる機会が増える
と思います。
とりあえず今回の僕の経験から言える事は、一連の処理を段階的に分割し中間
結果をオブジェクトとして渡すような設計を行う際には、段階間の責務の分析
を綿密に行った方が良い、ということです。。。
# もう少し一般化出来ないかな？
山崎 進 --- yamazaki@....jp
東京工業大学数理計算科学専攻柴山研