リファクタリングの定義とその誤解について

既存のシステムのインターフェースが変更されるのは、リファクタリングではなく、リアーキテクチャである。という話を耳にして、むむ、リファクタリングってインターフェース変えたらダメなんだったっけと思って、リファクタリング 第2版を再訪。
 
まずは定義のおさらいから。
外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること
少し定義を分解してみよう。この定義にはリファクタリングの目的、事後条件、その手段が含まれている。
 
リファクタリングの目的は「理解や修正が簡単になる」こと
目的を達成する手段として「ソフトウェアの内部構造を変化させる」
事後条件として「外部から見たときの振る舞いを保」たれていること
 
なるほど、「外部から見た振る舞いを保つ」と定義にある通り、ソフトウェアの内部構造が変更されても、ユーザーから見たソフトウェアの挙動が変わらなければ良いのか。
 
既存のシステムのインターフェースが変更されても、リアーキテクチャではなく、リファクタリングの範疇だった。認識間違ってなくてよかった。
 
そんなのどっちだっていいじゃんって話かもですが、こういうのが気になるのがエンジニアの性でしょう。多分ね。
 

このブログ書いた動機と外れるけど、せっかくリファクタリング読み直したので

雑多な読書メモ。

 
  • ソフトウェア設計の改善
  • ソフトフェアを理解しやすくする
  • バグの発見を助ける
  • プログラミングを速める
    • 既存のコードを資産として使えるため、開発と共に機能追加が容易になる
まとめると、、、素早く苦労せず機能追加する（雑）
リファクタリングのための工数を取りましょう。みたいな話があるけど、リファクタリングってそういうものではないんだな。
 
コード書いてる時に、コード読みにくいな。とかこの部分がこうなら、すっと機能追加できるのにな。とかそういうちょっとした不快感を取り除いていく作業なんだ。
 
間違っちゃいけないのは、リファクタリングは、僕の考えた最強の設計を披露するための言い訳ではないし、エンジニアの美的感覚をお披露目する場所でもない。
 
リファクタリングは、プログラミングを速くして、プロダクトを市場に出して、顧客からのフィードバックをもらい、機能をさらに修正して...というフィードバックのループを早く回すXPの実践の営みの中にあって、もっぱら経営的な理由から要請されるものというのは、エンジニアが肝に銘じておかないといけないんじゃないかな。
 
管理職にリファクタリングを断られるという話があるけど、管理職にリファクタリングは経営的な理由ではなく、エンジニアのエゴを満たすためのものと思われてる場合があるんじゃないかなと思った。