赤坂です。
Shibukawa Yoshiki <yoshiki@....jp> san wrote:
> (僕の大好きな)CRCカードが1つの答えになると思います。
これ良い方法ですね。
# 私は裏紙にラフスケッチしながら検討するスタイルが好きです。
> コーディングしながら僕がよく行うリファクタリングは
>
> １．責任が大きくなってきて太ってきたので分割
> ２．やせ細ってきたので、関連のあるクラス同士で合体
> ３．今使わない機能を思い切って切る
>
> の３種ぐらいですね。クラス間の依存関係が小さい構造になっていれば、変更時
> の気苦労も最小に抑えられるでしょう。それ以外のリファクタリングはあまり記
> 憶に無いです。
良い指針ですね。
# 私は貧乏性なので(?)、3.が難しいです(^^;;
> CRCセッションを行わないで、クラスをガンガン書き換えながら（リファクタリ
> ングとも言えないような荒っぽいやり方で）最初の開発を進めることもあります
> が、それはプロトタイプ開発なのである程度はしょうがないかな、と思っていま
> す。
そうですね。「使い捨て」のプロトタイプの場合には、細かいことは気にしなく
ても良いのではないかと思います。
> まとめると、
>
> １．ストーリーカード→タスクカードの間で責任分担を決める
> ２．責任分担はCRCセッションで行う
>
> いかがでしょう？
ペアないし、メンバーでCRCセッションを行うのは良いアイディアですね。
> CRCの入門は僕のCマガの記事(2003/5)でもいいんですが、本当に使うならピアソ
> ンの「実践CRCカード」を読まれると良いと思います。
渋川さんのこの記事、インターネットで拝見できないものでしょうか？
ではでは。
--
赤坂 英彦 (Hidehiko AKASAKA)
akasaka.h@....com