上手です。
refactorが話題になっているようなので、参考情報です。
> しかしもしかしたらXPは、あえてそれをよしとする（「場当たり的」はちがいま
> すが）方法論なのかもしれません。
>
> つまり、私なりの１つの解釈ではXPとは
>
> １．今見えている（必要だとされている）機能 *だけ* をプログラム
> する。
> ２．将来必要となる今は *見えない機能* は、それが本当に必要
> になるかどうかわからないので、今はプログラムしない。
> ３．機能がシンプル（必要最低限の機能）ということだけでなく、構造
> もできるだけシンプルでなければならない。柔軟性のためだけに
> 構造が複雑になるのならば、その柔軟性は将来必要になるかど
> うかわからないので、そのためだけのプログラム構造にはしない。
> ４．将来必要だと思われていた機能が、必要になった、その時点で
> その機能を作りこむ。しかし、この時場当たり的な修正はしない。
> Simpleかつ人間にわかりやすいように直すこと。
> ５．新しい機能を作りこむときに、今のプログラム構造に柔軟性がない
> 、あるいはSimpleかつわかりやすくならないと感じたら、まず必要
> な柔軟性、わかりやすさを持たせたあと（Refactoringして）、新し
> い機能を作りこむ。
xp explained chapter 17 p106 に下記の記述があります。
最初は very simple に実装する。２回目にそれを使う時は、より一般的
(general)にする。最初に使う時は必要な機能があればいい。２回目は
柔軟性(flexibility)を高める。使わないものの柔軟性は考慮しない。
柔軟性が必要とされるなら３回目、４回目、５回目と変更していく。
また、refactoring(fowler)は以下のように述べています。
refactoringの定義(P53)
より解りやすく修正をcheaperにするために、外部に対する振る舞い
(observable behavior)を変えずにソフトウェアの内部構造を変えること
P52 １章の実例の締めくくりで
この例の最も重要なlessonはrefactoringのリズムだ。
test,small change,test,small change,test,small change.
このリズムによりrefactoringがquickly and sefleyに動く。
P58 いつrefactoringするのか、と聞かれて
全てのケースでrefactoringのために特別の時間をとるのには反対だ。
refactoringはいつも少しずつやるものだ。refactoringはやろうと決める
ものではなくて、何か別のことをしたい時にrefactoringがそれをするの
を助けてくれるんだ。
Don Roberts がくれたガイドラインがある。
何かを最初にする時は、それだけをやれ(just do it）
２回目は、duplication をとれ(wince)
３回目は、refactorしろ
また、p57で「rapid ソフト開発ではよいデザインは基本だ」と主張して
いますので、彼らがいっている「動けばいい」というのは、結構レベル
が高い気がします。fowler や cunninghamはパターンの権威でもある
ようですし。
（以上）
>
> 要は最初から柔軟性、再利用性を確保しておく必要はなく、それが
> 必要になったときに行えばよい。ということではないかと思います。
>
> ですから、
>
> XPは柔軟性、再利用性に対立するものではない。しかし、それを
> やみくもに行うことには反対する。必要な時に必要な程度で行う。
>
> ということでしょうか？？
>
>
> --
> 矢崎博英 firo@....jp
>