第1章はサンプルコードをベースにした「体験版」的な内容なので、読書メモは第2章から。
リファクタリングの定義
リファクタリング(名詞):外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること。 – p.53
リファクタリングする(動詞):一連のリファクタリングを適用して、外部から見た振る舞いの変更なしに、ソフトウェアを再構築すること。 – p.54
リファクタリングの目的は、ソフトウェアのコードを理解しやすく、変更しやすくすること。そのために重要なのが、外的な振る舞いを保つこと。
コードを書く際には、機能追加とリファクタリングという「2つの帽子」のうち、自分が今どちらの防止をかぶっているのか意識すべき。
リファクタリングを行う理由
- リファクタリングはソフトウェア設計を改善する
- リファクタリングはソフトウェアを理解しやすくする
- リファクタリングはバグを見つけ出す
- リファクタリングでより速くプログラミングできる：優れた設計は開発が進んでも速度が落ちない
いつリファクタリングをすべきか
- 3度目の法則：同じようなコードを3回書いたらリファクタリングする
- 機能追加の時にリファクタリングを行う
- バグフィックスの時にリファクタリングを行う
- コードレビューの時にリファクタリングを行う
管理者を説得するには
- 管理者が品質を重視するタイプなら：リファクタリングを行うことでソフトウェアの品質が向上する点を強調する
- 管理者が品質よりスケジュールを重視するタイプなら：管理者に無断でリファクタリングする
最も速い方法はリファクタリングです。だからリファクタリングをするのです。 – p.61
リファクタリングの問題点
- データベースのリファクタリングはソフトフェアに比べると非常に難しい
- インタフェースの変更：「published」メソッドのインタフェースを変えるのは非常に難しい
「published」とは、publicよりもさらに広く公開され、変更が困難なこと。具体的には、一般公開されているライブラリに含まれるpublicメソッドなど、書き手がそのメソッドの使用箇所を全て探しだして変更することが困難な状態になったメソッドのこと。この場合、インタフェースを変更するなら、古いインタフェースを残しつつ新しいインタフェースを提供する、という形式になる。
- リファクタリングしにくい設計：どんなに間違った設計でもリファクタリングできるか、という問いに対しては、明確な答えはまだない
リファクタリングを避ける時
- 変更するよりも最初から書き直したほうが早い時
- 納期が迫っている時：リファクタリングによる生産性の向上は後々効いてくるものなので、納期前にリファクタリングをしても速度は上がらない。
リファクタリングと設計
リファクタリングには、設計を補完する役割がある。リファクタリングを行うことで、事前設計を改善していくことができる。
リファクタリングとパフォーマンス
リファクタリングを行うことで、コードのパフォーマンスが低下することもある。一般に、パフォーマンスの最適化には以下のようなやり方がある。
- 時間分割：各コンポーネントが使用可能なリソースの上限を決め、その上限を厳守する。組み込み系などで必要となることがある。
- パフォーマンスを常に意識する：コードの全体にパフォーマンス最適化を行う。その結果、コードが読みづらくなることが多い。
- 90%の法則：全体の90%は読みやすく保ち、パフォーマンスに影響を与える10%をチューニングする。
Webアプリケーションの場合、パフォーマンスを低下させる箇所は決まっているので、90%の法則が適している。
パフォーマンスチューニングで重要なのは、「推測せず、計測せよ」。
リファクタリングの起源
Smalltalkを使っていたWard Cunningham と Kent Beck が中心的人物。Smalltalkには、コンパイルの速さとオブジェクト指向という、リファクタリングに向いた性質があった。
第1章はいきなりサンプルコードが出てきて、それをリファクタリングしていくという、とても具体的な内容だったのに対して、第2章は抽象的な議論が中心だった。続く第3章は「コードの不吉な臭い」について。