渋川です。
> > 私は，SRP(Single Responsibility Principle＝単一責務の原則)を，
> >「自然な責務」と考えています．また，Robert Martin は，より現代的に，
> > Responsibility = Reason to Changeして変更の理由を責務と捉えています．
>
> この視点もとても納得できるものです。
>
> ただまだ私にはわかっていない点があります。それは、XPが登場した当初
> からこれを原則あるは重視している場合は、漠然とXPとは相容れないような
> 感じをもっていたのですが、この感覚が正しいのかおかしいのかが今だによく
> わかっていないという点です。
(僕の大好きな)CRCカードが1つの答えになると思います。
僕は巨大なXP開発はしたことありませんが、ストーリーカードを書き、必要そう
な要求がある程度集まったらCRCセッションを行います。ご存知の方も多いと思
いますが、CRCはクラス・責任・協調の頭文字です。コードは書きませんが、CRC
セッションの中で大雑把なクラスごとの責任分担を決めていきます。ビッグリフ
ァクタリング、および、クラスレベルのリファクタリングはCRCカードレベルで
行えるものも多いので、CRCセッションの中である程度クラス構造なんかを洗練
させてしまいます。
CRCセッションは厚さ数センチもの仕様書を書くような作業ではないので、XPの
嫌う巨大な前設計とは異なります。チーム間でソフトウェアの構造のコンセンサ
スも取れるし、設計もできるし、ある程度の作業量が分かるのでタスク分割も行
えるようになります。なおかつ、クラスごとの依存関係まで分かってしまうので
スタブを作らなくてもすむ作業手順まで分かります。一石四鳥です。ファンタス
ティックですね。
> 自然にパタンの適用やインターフェース間のプロトコルの設計、構造
> （仕掛けを含む）の設計を伴ってしまうからです。そうでないとしっくり
> こないのです。そして、この責務を重視したアプローチはかなりしっかり
> したモデリングやコアな部分の作りこみを自然と伴いそこから見るとXP的
> ではないように感じたということです。
プロトコルの設計は僕は上記作業では行いません。依存関係の無いものから順番
に開発できるからです。あまり並列度の高い開発をしたことが無いから必要にな
ったことがないだけかもしれませんが。CRCセッションで意識するパターンは
SingletonとTemplate Methodぐらいかな？後はコーディング時に考えます。
コーディングしながら僕がよく行うリファクタリングは
１．責任が大きくなってきて太ってきたので分割
２．やせ細ってきたので、関連のあるクラス同士で合体
３．今使わない機能を思い切って切る
の３種ぐらいですね。クラス間の依存関係が小さい構造になっていれば、変更時
の気苦労も最小に抑えられるでしょう。それ以外のリファクタリングはあまり記
憶に無いです。
CRCセッションを行わないで、クラスをガンガン書き換えながら（リファクタリ
ングとも言えないような荒っぽいやり方で）最初の開発を進めることもあります
が、それはプロトタイプ開発なのである程度はしょうがないかな、と思っていま
す。
プロトコルの設計は「責任」というよりも「契約」と呼ばれるんじゃないでしょ
うか？責任の設計は重要だと思います。契約は後に延ばせるならばできるだけ延
ばします。
まとめると、
１．ストーリーカード→タスクカードの間で責任分担を決める
２．責任分担はCRCセッションで行う
いかがでしょう？
CRCの入門は僕のCマガの記事(2003/5)でもいいんですが、本当に使うならピアソ
ンの「実践CRCカード」を読まれると良いと思います。
-----
東京工業大学 国際開発工学専攻 上田研
_/_/_/ しぶかわよしき JA6HFA/1 yoshiki@....jp
_/ http://www.shibu.jp http://www.unittest.org