寺田です．
Narushima さん：
> プログラミングにおける「型」といっても、私が想像できる型は「テストを先
> に書く」くらいで、あとはその場その場で違うんですよね。そのテストの定義
> の仕方、作り方ですら、それぞれのシーンによって違いがある。デザインパ
> ターンや、リファクタリングは、こだわったほうがいい場合もあれば、よくな
> い場合もあるのが悩ましい。
私のイメージする「型」というのは単なるパターンとは違うんです．ですから，
プログラミングのスタイルを単純なパターンに押し込めようという意図ではない
のです．
むしろ，Narushima さんが仰るような
「その場その場で違う」「それぞれのシーンによって違う」
という微妙なニュアンスを（も）身に付けられるようなトレーニング方法を目標
としています．
このような微妙なニュアンスは言葉で説明されても習得は難しいですよね．とい
うか，なんとも言葉にしがたいものがあります．
では，出来る人というのはその言葉にしがたい微妙なニュアンスをどのようにし
てつかみ取ってきたのか，と考えますと，これは多くのコーディングを繰り返し
てきた経験の賜物としかいいようがないのです．このような言葉にしがたい暗黙
知をより効率的に習得するにはどんなトレーニングが良いのでしょうか．
それには，達人の書いたコードを何度も反復するのが効くのではないかと思った
のです．達人のコードには微妙なニュアンスが織り込まれていますから．
最初はそのニュアンスに気づくことはないでしょうが，何度も反復して味わうう
ちに微妙なニュアンスに気づく瞬間が来るかもしれません．そんな効果を期待し
ています．
ですから，私のイメージする「型」は，パターンというよりはパターンのインス
タンスです．「ケースバイケース」の一言で済ませるのではなく，その代表的な
ケース一つ一つを抜き出したものです．
※ うーん，説明しにくい．この文章で意図が伝えられるか不安です・・・．
> ある程度の「型」はXPのプラクティス自体が提供していると思います。それ以
型とプラクティスは違った概念です．（分かりにくくてすいません）
型はプラクティスそのものではなく，プラクティスの *優れた* インスタンス，
という感じです．
「テストを先に書く」というプラクティスは一種の「行動規範」であって，この
規範に則った行動は複数考えられます．つまり，「その場その場で違」います．
この「その場その場で違」うものを一つ（或いは複数）抜き取ったものが「型」
です．
ヘンな喩えかもしれませんが・・・．
プログラムの構造を説明するときに，オブジェクト図を使用するやり方とクラス
図を使用するやり方がありますよね．つまり，実際に起こりうる具体的なオブジェ
クトの配置例を示して構造を説明するか，一段メタなレベルであるクラス構造を
示すことによって説明するか，です．
「型」はオブジェクト図に相当する概念だと思ってください．
> 私も斎藤孝の著作物は好きで、ファンなんですけども、斎藤氏が言うには「テ
> ニスが上手くなるには自分より上手い人と打ち合うとよい。上手くなるよう合
> わせてくれる」てなことを言っていて、プログラミングも同じように、上手い
> 人と下手な人が一緒に作業するのが一番ですね。
はい，それはそうだと思います．
ペアプログラミングを否定するつもりは毛頭ないです．
> トレーニングには、しいていうなら、適切なプログラミング言語、ライブラ
> リ、フレームワークを選択することがポイントかも。
ライブラリやフレームワークはともかく，言語に関しては各言語ごとにトレーニ
ングがあるのが理想でしょうね．
ではでは．以上です．
--
Y.Terada <terada@....jp>