塚本です。
公正を期すために補足します。
実をいうと、柔軟性は最初から確保できなくても良い、refactoring で徐々に
高めることができる、という主張には大筋で同意しております。
>>>>> "佃" == 佃 軍治 <tsukuda@....jp> writes:
佃> 「将来すれば済むことは将来する」ことを判断することは難しく、
佃> 判断するためには、結局開発対象のユースケースから抽出されたク
佃> ラスと関係がありそうなクラスを他のユースケースからすべてリス
佃> トアップするなどの作業を実施することになるのではないでしょう
佃> か。そのため、そのイテレーションで検討すべきことが多くなって
佃> しまい、検討内容が複雑になるのではないでしょうか。
なるほど確かに、将来に備えるためには上記のような複雑さが懸念されますね。
開発に新規性がある以上、フレームワークなどの下地が整備されていない領域
は常に存在するのですよね。そうした領域では、早々と将来を見切って柔軟性
を確保しておくのは極めて困難なことでしょう。
しかし、将来に備えないという境地にはなかなか到達できません。モデルでは、
アナリシスパターン等を手本にして将来に備えておく方が良い気がしています。
考えようによっては "simplest" も実装詳細に関わる一要因であり、モデルが
そこに特化するとシステムそのものが「短命」に陥る気がするのです。
モデルでスパイラルを回すことに反対しているわけではないのですよ。ただし、
実装コードの refactoring ほど頻繁には更新できないでしょう。また、実装
レベルならばテスト仕様を維持しつつ refactoring 出来ても、モデルの変更
はテスト仕様にかなりのインパクトを及ぼすはずです。
私としては、
(最初は) 見切れない将来に対して、モデルは短命にならないよう備える。
その一方、テストケースや実装コードは simplest にする。
(途中は) 変化を抱擁することを目指して、refactoring を繰り返す。
(最後は) 見切れた領域に対する整備された下地の利用を主にして、
コード記述はほとんど必要無いようにする。
ような工程を目論んでいます。最後の状況は XP から外れるかもしれませんが、
やはりそこをゴールにしたいのです。
また、整備の行き届いた下地は再利用性の代償に、どんな特定の要件にとって
もいくらか overkill 気味にはなるでしょう。先の「MVC を使うか否か」云々
もその一例だったかと思います。
--
Yoshihiro Tsukamoto