沖田さん，
平鍋です．おはようございます．
On Thu, 12 Apr 2001 10:57:55 +0900,
Naoyuki Okita <Naoyuki_Okita@....jp> said:
> 私の個人的な考えになりますが、
> 大きなリファクタリング(名詞 *1)とアーキテクチャジャンプは、結果としてか
> なり似ているのではないかと思います。
> また、アーキテクチャジャンプを実施する手段として、大きなリファクタリング
> (動詞 *2)することになるのでは？と思います。
私の感覚と非常に近いです．リファクタリングの12章を読み返し
て，再度，その感を強くしています．
> あえて、「結果として」と書いたのは、動機が違うこともあるからかな？と思っ
> てためです。
> 下図に、私が思った大きなリファクタリングとアーキテクチャジャンプの関係
> を示します。
> 大きなリファクタリング
> +------------+
> | | アーキテクチャジャンプ
> | +-------+---+
> | | | |
> | B | A | D |
> | C | | |
> | +-------+---+
> | |
> +------------+
> ・Aは大きなリファクタリングとアーキテクチャジャンプの動機も結果も重なる
> 領域で、多くの事例がここになるのではないかと思います。
> 私が、最初に大きなリファクタリング==アーキテクチャジャンプと、質問したの
> もここを想定していました。
> ・Bはアーキテクチャ不在の混乱状態になったプログラムを叩き直す場合。
> ・Cは局所的な限界点には達していないが、おそらく限界点を超えそうなので、
> アーキテクチャを見直す場合。
> (XPだと、やはり変更が発生＆限界点に達したとなるまでは、局所解を目指すの
> でしょうか？)
達することが分かるストーリーが現れた時点で見直すと思います．
必要とするストーリーが現れないのに着手するのは，YAGNI 違反で
しょう．
> ・Dはリファクタリングで、稼動しながら変更するのではなく、作り直してしま
> え！という場合
> (正しいXPのアプローチかどうかは自信がありません。)
アーキテクチャ，と行った場合，リファクタリングを超えた射程を
持つでしょう．例えば，言語を替える，ミドルウェアやクラスライ
ブラリをすっかり取り換えてしまう，分散環境で実装する，などな
ど．少なくとも大きなリファクタリングで上げられているクラス階
層の大幅な変更，以上のジャンプを感じます．開発途中でこれらを
替えることが，「変化を抱擁する」範疇かどうかは，はてな，です
が．
> 「リファクタリング」より
> *1) リファクタリング(名詞):外部から見たときの振る舞いを保ちつつ、理解や
> 修正が簡単になるように、ソフトウェアの内部構造を変化させること。
> *2) リファクタリングする(動詞):一連のリファクタリングを行って、外部から
> 見た振る舞いの変更なしに、ソフトウェアを再構築すること。
ただ，大きな意味では，上記定義から，アーキテクチャジャンプ
はリファクタリングとも言えますねぇ．
以上