リファクタリング 第2版 既存のコードを安全に改善する OBJECT TECHNOLOGY SERIES

マーチン・ファウラー(著者), 児玉公信(訳者), 友野晶夫(訳者), 平澤章(訳者), 梅澤真史(訳者)

• 販売会社／発売会社: オーム社
• 発売年月日: 2019/12/01
• JAN: 9784274224546

商品レビュー

2025/11/11

## 手に取った動機
結構大規模なリファクタリングをする機会が訪れそうで。いつ、どこまで、どうやるべきかに悩んで手に取ってみた。

## 以下がとても良かった

p47.
リファクタリングなしでは、プログラム内部の設計（アーキテクチャ）は徐々に劣化していきます。
開発者が短期的な目的の実現のために、アーキテクチャの全体的な理解をせずに変更を行なった場合、コードは構造を失うことになります。
こうなると、コードを読んで設計を把握することも難しくなります。
そしてコードが構造を失うと、累積的に悪影響が及びます。設計が把握しづらくなるにつれて、それを維持するのが困難になり、急速に劣化していきます。
リファクタリングを定期的に行うことで、コードを良い状態に保つことができます。

p48.
そのコードをリファクタリングできれば、何をしているのかがわかるようになり、その新たな理解を武器に、コードに立ち向かえるようになります。
プログラムの構造を明確にすることで、コードに対する推測が正しかったことがわかり、やがてバグを無理なく発見できるに至ります。

ここで、Kent Beckが自らを語ったセリフを思い出しました。
「僕は、偉大なプログラマなんかじゃない。偉大な習慣を身につけた少しマシなプログラマなんだ。」

p50.
内部の設計が優れているソフトウェアは、新たな機能を加える際にどこをどう変更すれば良いか、すぐに把握できます。
私はこの効果を「デザインスタミナ仮説」と呼んでいます。内部の設計を入念に行えば、ソフトウェア開発のためのスタミナをつけることができ、より長い期間、より早いペースで開発していくことができます。

p51.
例えるなら、100マイル東に行きたいのに、ただ森を分け入るのではなく、まず20マイル北の高速道路まで車で行き、そこから本来の3倍の速さで100マイル東に進むようなものです。
誰かが「まっすぐ行け」と急かしてきても、「待って、地図を確認して一番早いルートを見つけないと」と言う必要がある時があります。
準備的なリファクタリングは、私にとってまさにその役割を果たしてくれるのです。

FYI: https://martinfowler.com/articles/preparatory-refactoring-example.html

p52.
手始めに、理解のためのリファクタリングを細かく行うようにします。変数名をいくつか修正して、それぞれが何を表すのか理解できるようにしたり、長い関数を適宜分割したりします。
コードが明確になるにつれて、以前は気づかなかった設計上の考慮すべき事項が把握できるようになります。

p53.
変更の要求が来たら、まず変更が容易になるようにする。それから、容易になった変更を行う。

https://x.com/kentbeck/status/250733358307500032

p57.
私が最も危険な罠と思うのは、「美しいコード」「素晴らしいエンジニアリングのプラクティス」といった道徳的な理由により、リファクタリングが正当化される状況です。
リファクタリングは、コードベースがどれだけ美しいかではなく、純粋に経済的な基準で図られるものです。

リファクタリングするのは、あくまでもスピードを上げるため、新機能の追加やバグの修正を早めるためです。
そのことを常に心に留めるべきですし、メンバーにもその観点を持って接していく必要があります。

2025/06/02

先人の知恵やテクニックが盛り込まれている良書である。何度も読み直して、また、実践して、知識として定着させたい。

2025/04/14

現場でなんかイマイチだなー、と思ったコードは、不吉な匂いという概念で表現されていた。見える世界が変わった気がする。一度に理解し切るのは難しいので、繰り返し読みたい。
途中比喩がわかりづらい部分あったので、Chat GPTに聞いて理解を深めた。