赤坂です。
Susumu YAMAZAKI <yamazaki@....jp> san wrote:
> > すみません、素朴な疑問なのですが、
> > 1:9の法則は初耳なのですが、20-80の法則とは異なるものでしょうか？
>
> 同じ物です。どちらも聞くので少し悩んだのですが、今回の場合比率がどちら
> かと言えば 1:9 の方が近いような気がしたので、1:9 と書いておきました。
> 20-80 の法則と言った方が一般的だったかもしれません。
了解しました。
# 私の不勉強でした。ごめんなさい。
> > コードの修正については、ある程度覚悟が出来るものですが、
> > 影響するテストケースの修正についてはガックリしますよね。
> > ＃ やっぱり単体テストに外部パッケージへの依存を持たせてはいけないのでしょうか？
>
> 理想的には依存がない方が良いでしょう。しかし今回の場合、中間結果オブジェ
> クトに情報を格納するので、必然的にテストケースが中間結果オブジェクトに
> 依存します。このような場合にどのようにコード／テストケースの設計をする
> のが理想的なのか、皆さんにご意見を伺いたいです。
私も知りたいです。
皆さんのご意見を伺いたいですね。
> 大まかなアーキテクチャを決定するのは(ペア)プログラミング以前であるべき
> だというのは、その通りだと思います。一度学生達に分散ドローツールをXPも
> どきで開発してもらったのですが、途中でアーキテクチャの変更を迫られ、非
> 常にコストがかかったという事がありました。その教訓から、大まかなアーキ
> テクチャに関しては詳細な分析が必要だというのは賛成です。
はい。
> 僕が問題にしているのはその後の話です。先程の一連の処理を分割した例でも
> 大まかなアーキテクチャに関してはプログラミング以前に決定していたわけな
> のですが、開発中に責務の分割を見直す必要がある例を発見したので修正が必
> 要になりました。この時の反省点として、要求仕様が変化した訳ではないので
> 責務の分析をもっとしっかり行っていれば、修正を回避する事が出来たのでは
> ないかと考えた次第です。
>
> > 後は、実現するタスクカードごとに合意の取れたアーキテクチャへの影響(変更
> > しなければならない部分)を見て、分析したほうが良いかどうか判断するのでしょ
> > うかね。
>
> もう少し先程の例の問題点を分析しますと、ストーリーをタスクに分割し、タ
> スクカードを見ながら開発を進めて行った際に、タスクカード全体を見渡さず
> に一枚一枚のタスクカードの実装に専念してしまったために局所解に陥ってし
> まったのが、修正が必要になった一番大きな理由です。
>
> しかし、タスクカードが非常に多かったため、開発前の段階でアーキテクチャ
> への影響をきちんと分析しないうちに見切り発車で実装を進めてしまったのが
> 後で問題になりました。
要求が変化したわけではなく、影響の検討漏れということでしょうか。
私の場合、RUPベースで分析、設計を行っていても、影響が見切れていなかった
ということはよく経験します（あまり、誉められたことではありませんね）。
> 最初の時点でこの部分の分析を深く行う必要があるという認識があれば問題を
> 回避できたのですが、その判断を助ける「前兆現象」「不吉な臭い」を捉える
> 方法が整理されていれば、経験の浅い人でも正しい判断を下せる機会が増える
> と思います。
これらはパターンカタログの様に整理されていれば誰でも判断を下せるものなの
でしょうか？
もちろん、方法が整理されていた方が良い結果に繋がるとは思いますが、私はこ
れら正しい判断を下すには経験を積むことが必要なものと考えています。
というのは、整理する視点が難しく、誰でも分かる視点で整理すると量が膨大に
なり、抽象度を上げて量を減らすと経験の浅い人には伝わらないのかもしれない
と思うからです。
# 勝手な思い込みなのかもしれませんけど。
> とりあえず今回の僕の経験から言える事は、一連の処理を段階的に分割し中間
> 結果をオブジェクトとして渡すような設計を行う際には、段階間の責務の分析
> を綿密に行った方が良い、ということです。。。
はい、その通りだと思います。
--
赤坂 英彦 (Hidehiko AKASAKA)
akasaka.h@....com