概要
「リファクタリング第 2 版」を読みました。 「前提（目的、前提知識）」「読了時間」「感想」「次に関連で勉強すること」「まとめ」を記述します。
前提
目的
主な理由は以下です。
- さまざまな書籍で紹介されるため、読みたかった
- 自身が興味のある設計やドメイン駆動設計の文脈でも紹介されることが多かった
- 業務でリファクタリングが必要なコードと遭遇することが多く、リファクタリングそのものを学びたかった
前提知識
設計関連（主に DDD）では以下の書籍を読んでいました。
リファクタリングについて時間をとって勉強しようと思ったのは以下の書籍などがきっかけです。
読了時間
5 週間かけて勉強会を開催しており、毎週 4 ~ 6 時間の準備時間と当日は 1.5 時間かけていました。 そのため、だいたい 32.5 時間ぐらいかけて読み切りました。
感想
リファクタリングができるパターン（不吉な臭い）と、一般的なリファクタリング方法が網羅されており非常に参考になりました。 当初の目的を達成し、リファクタリングについては、どの本よりもまず最初にこれを読むべきだとおすすめできるぐらいになりました。 しかし、オブジェクト指向（OOP）について関心がなかったり普段使用している言語が OOP じゃなかったりすると、読み進めるのが難しかったり参考にならなかったりする可能性があります。 よかった点と気になった点について記述します。
よかった点は 3 つあります。
1 つ目は、リファクタリングを単に紹介するだけでなく、適用するための周辺知識や逆パターンなども記述されていることです。
一般的な記事や書籍では「このような場合は、こうやったらできます」で終わってしまうパターンが多いです。この書籍では、「なぜ」を深堀しており、やりすぎてしまったら逆に戻すパターンも紹介されています。
カタログのサンプルコードも長すぎず、解説が理解できなかったら簡単な写経で解説に沿った手順でリファクタリングを理解できます。
「一旦試す」「相談する」「確定する（or 戻す）」の流れをこの本を読むことで可能になると思いました。
これはリファクタリングに明確な対処法があるわけではなく、時間経過と共に再度設計し直さなければならないことを認識できました。
個人的には、式を変数で定義またはインライン化なのか迷う場面が多かったんですが、「「変数の抽出」を検討するのは、コードないの式に名前を付けたいときです。」と記述されており 1 つの基準を持てました。
2 つ目は、リファクタリングだけでなくソースコードを書くときに意識するべき金言がいたるところにあることです。リファクタリングの言葉の定義（外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること）だけでなく、以下のような言葉が記述されていました。
- すばらしいコードもリファクタリングを必要とする
- リファクタリングは、コードベースがどれだけ美しいかだけではなく、純粋に経済的な基準で測られるものです
- （不吉な臭いに「コメント」を上げた理由として）ここでコメントについて言及しているのは、コメントが消臭剤として使われることがあるからです
- （いつコードを独立した関数として取り出すかという議論に対して）しかし、最も納得できるのは意図と実装の分離です
- etc
ほんの一部抜粋で、他にも核心をついた言葉がたくさん紹介されています。 これらを意識するだけでも、意識する前とソースコードに質が変わることは間違いありません。
3 つ目は、OOP についてです。言語は JavaScript ですが、途中から実践していることが手続き的な書き方から OOP による高凝集疎結合な設計になります。 具体的にはカプセル化、オブジェクトの受けた渡し、サブクラスの作成、条件分岐の明確化、ポリモフィズムなどです。 Martin Fowler による OOP を意識した設計は、リファクタリングに限らないコーディングの指針になります。 DDD を長い期間にわたって学んできたことから、OOP に強い興味をもっているため、予想していない部分で知見を得られました。
気になった点は 3 点あります。
1 つ目は、テストコードがないことです。
振る舞いが変わらないことを確認するためにはテストコードが必要ですが、序盤を除けば中盤以降のカタログの部分にテストコードがありません。
カタログの内容が途中で正しく写経できているのかわからなくなったときにテストコードで確認できないため、リファクタリングの効果が半減していると思いました。
2 つ目は、JavaScript についてです。本書は第 2 版により Java から JavaScript になったため、手元で再現しやすくなっています。ただし、JavaScript じゃない静的型付け言語だったら（Java でも）もっと楽にリファクタリングできたり、不吉な臭いがするコードにならないのではないかと思ってしまう部分が多かったです。具体的には以下です。
- 動的型付け言語であること。型がないのでリファクタリング後も見通しがよくなっても、安心できない部分が多かった。静的型づけ言語であれば、もっと簡単にリファクタリングできると思えてしまった（それも含めてカタログにはテストコードも欲しかった）
- interface がないこと。途中でポリモフィズムを意識したコードが紹介されますが、どれも継承を使っていました。interface があればもっと綺麗に解決できるたり、interface の強力さを実感できたりできるので、interface について言及がなかったのは残念でした
- 現在 JavaScript を実践している層は、OOP の書き方ではなく、モダンフロントエンドの宣言的な書き方を使用している場合が多いこと。そのため、普段「（フロントエンドで）JavaScript を使っているから読みました」という人向けではなさそうだし、メリットや OOP の書き方に理解できなさそう
逆に言えば、JavaScript みたいな動的な言語でも、実践できることを証明しています。 また、型がある言語の場合は、本書を読めば簡単にリファクタリングできるようになる（テストコードの実装を除けば）と思いました。
3 つ目は、OOP 前提なことです。 前述しましたが、途中から OOP による高凝集疎結合なソースコードを目指していきます。 個人的には共感できる部分が多かったんですが、OOP のメリットを理解できていなかったり、Go やフロントエンドなどの OOP 以外のやり方を採用していたりすると、理解が難しい部分もあったと思いました。 その点では、「現場で役立つシステム設計の原則」や「なぜオブジェクト指向で作るのか」などを一読して、OOP のメリットを簡単に触れてから読んでほしいと思いました。
次に関連で勉強すること
この本を読んで、設計とオブジェクト指向に興味を持ったので、以下の本に着手していきます。
- 「レガシーコード改善ガイド」
- 「レガシーソフトウェア改善ガイド」
- デザインパターン関連の書籍
まとめ
噂通り、リファクタリングについて知見（手法、思想など）を深められる名著でした。ついでに、OOP に対する知見も深められます。 気になった点（サンプルコードにテストコードがない、JavaScript、OOP 前提）については他の書籍で軽く触れたほうがいいと思いました。 この本をベースに他の本も読んでいきます。
