Chapter 2

第二章 リファクタリングの原則

この章ではコードは出てこない。

ここでは一歩下がって、リファクタリングの重要な原則やリファクタリングを利用する上で考えなければならない問題点などを見ていくことにしよう。

という章。

2.1 リファクタリングの歴史
リファクタリングが最初に実践されたのはSmalltalk上での開発だった模様。
Martin Fowler がリファクタリングを知ったのは1992年。

2.2 リファクタリングの定義
p.76最下部

リファクタリング(名詞):外から見えるふるまいを変えずに、ソフトウェアをわかりやすくし、安いコストで変更できるようにするために、ソフトウェアの内部構造に加えられる変更。

リファクタリングする(動詞):外から見えるふるまいを変えずに、一連のリファクタリングを適用してソフトウェアの構造を変えること。

「ふるまいを変えない」というのが重要。機能を追加するときは、既存コードを書き換えることなく機能追加に集中する→Kent Beckの「二つの帽子」の比喩

2.3 リファクタリングする理由
読んでの通り。以下は本文中の小見出し。
リファクタリングはソフトウェアの設計を改善する
リファクタリングはソフトウェアをわかりやすくする
リファクタリングはバグを見つけやすくする
リファクタリングはプログラミングをスピードアップする

2.4 リファクタリングはいつすべきか
3度目の原則(同じようなことを3度目にするときはリファクタリングせよ)
機能を追加するとき
バグフィクスが必要になったとき
コードレビューをするとき
理解を深めたいとき

2.5 リファクタリングが有効なわけ
プログラムが扱いにくく鳴る4つの原因

1. 読みにくいプログラムは書き換えにくい
2. ロジックの重複のあるプログラムは書き換えにくい
3. 機能の追加によって、動いているコードを書き換えにくい
4. 条件分岐が複雑なプログラムは書き換えにくい

リファクタリングはこれらの原因を解消する。

2.6 管理者とはどう交渉すればよいか
品質面を強調する
日程を強調される場合は、何もいわない(リファクタリングを使った開発が結局一番早い)

2.7 間接化とリファクタリング
Kent Beckの署名のある節。
間接化は基本的に避けるべきだが、システムの現在の動作を保ちながら、品質を向上させるか、コストを削減することができる箇所があればそこに間接化を導入するのは理にかなっている。
逆に、ただコードをわかりにくくしている間接化はリファクタリングで排除する。

2.8 リファクタリングの問題点

インターフェイスの変更 公表した"pubjlished"インターフェイスの変更は危険。少なくともユーザーが変更に対応できるようになるまでは新旧両方のインターフェイスを維持すべき。これを避けるため、中途半端にインターフェイスを公表しない。

データベース
必要があれば、オブジェクトモデルとデータベースモデルの間に別個の階層を挿入する

リファクタリングが難しい設計変更
結論から言うと「意外と大丈夫」。フレームワークやインテグレーション技術の選択は軽々に行うべきではないが。

リファクタリングを避けるべきときはいつか

1. 0から書き直すとき
2. 現在のコードが動かないとき
3. 納期が非常に間近まで迫っているとき(非常に間近まで迫っているのでなければ、時間不足はリファクタリングが必要な兆候なので、避けてはいけない)

2.9 リファクタリングと設計
リファクタリングを導入すると、設計は「完璧」でなくともまずまず妥当であれば良い
→設計に単純さを求めるようになる

「柔軟な設計」は実は結構難しい

2.10 何も作らなくなるまでには時間がかかる
Ron Jeffriesの署名のある節
パフォーマンスのボトルネックについて、推測よりプロファイラによる計測が大事だったという経験談。

2.11 リファクタリングとパフォーマンス
心臓ペースメーカの制御プログラムのような例外を除き、パフォーマンス向上はプロファイラとリファクタリングの組み合わせが一番使える。
たいていの場合、実行時間の大半はコードのごく一部で浪費されているので、プロファイラでそれを特定し、リファクタリングで改善していく。

2.12 給与管理システムの最適化
Rich Garzanitiの署名のある節。パフォーマンス調整の実例。