概要
「レガシーコード改善ガイド」を読みました。 「前提（目的、前提知識）」「読了時間」「感想」「次に関連で勉強すること」「まとめ」を記述します。
前提
目的
主な理由は以下です。
- 自身が興味のある設計やドメイン駆動設計の文脈でも紹介されることが多かった
- 直前に読んだ、「リファクタリング第 2 版」でも紹介されていた
- 業務のコードもレガシーコードと呼べるもので、どう改善すればいいのかきになっていた
前提知識
設計関連（主に DDD）では以下の書籍を読んでいました。
- 「現場で役立つシステム設計の原則」
- 「ドメイン駆動設計モデリング/実装ガイド」
- 「ドメイン駆動設計サンプルコード&FAQ」
- 「実践ドメイン駆動設計」
- 「ドメイン駆動設計入門」
- 「リファクタリング第 2 版」
リファクタリングについて時間をとって勉強しようと思ったのは以下の書籍などがきっかけです。
読了時間
5 週間かけて勉強会を開催しており、毎週 4 ~ 6 時間の準備時間と当日は 2.0 時間かけていました。 そのため、だいたい 35.0 時間ぐらいかけて読み切りました。
感想
レガシーコードが生まれる原因や、それに対応する手法や金言についてまとめられた良書でした。しかし、原著が 2004 年に出版され前提が変わってきている部分もあり、個人的には万人に薦められないなと思いました。 よかった点、気になった点をそれぞれまとめていきます。
よかった点
よかった点は 3 つあります。 1 つ目は、リファクタリングに対する金言がまとめられていることです。 表紙の帯にも書いてある「テストがないコードはレガシーコード」のほかに以下のことが記述されていました。
- システム変更の方法は、編集して祈ると保護して祈る
- コードを変更するためには、テストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある（レガシーコードのジレンマ）
- 変更をリファクタリングと呼べるのは振る舞いが変わらない場合だけ
- よくメンテナンスされたシステムであっても、変更に対応する方法を見出すのはそれなりに時間がかかる（しかし変更は簡単で、レガシーコードはどちらも困難）
- private メソッドをテストしなければならない場合、そのメソッドは public にするべきだ
- 良い設計はテスト可能、悪い設計はテスト不可能
- システムのストーリーを話す
- 直行性とは、非依存を格好良く表現した言葉。コードのもともとの振る舞い変更したい時に、変更しなければならない場所が 1 つだったときのこと
2 つ目は、リファクタリングの戦術的な説明です。 今まで、「こうすれば上手くいくし今後にも役立つ」手法はなんとなく認識していたものの、言語化されたものが本書籍に載っていました。 また、具盾的な例をあげると以下になります。
- 「テストハーネス」ソフトウェアの一部やコードを動かすために書くテストコード
- ソースコードの変更理由は 4 つ（要件追加、バグ修正、リファクタリング、最適化）である
- スプラウトメソッド、スプラウドクラスによって、テストコードのないコードから派生させたテストコードを書く
- 「指向リファクタリング」コードを checkout して、検証のためにリファクタリングすること
- 責務の把握をするための 7 つの経験則
- テスト駆動開発とペアプロで素早いフィードバックを得たり、単一目的の編集をおこなう
3 つ目は、オブジェクト指向の良い部分を引き出しているリファクタリングをしていると思いました。 割と個人的な感想になりますが、責務をどうやって分割と集約をさせたりとか、interface を用いた DI がいかに疎結合にしてくれるかなどを繰り返し解説してくれます。 簡易的な、「なぜオブジェクト指向で書くのか」になっているので、共感を得られました。
気になった点
気になった点は 2 つあります。
1 つ目は、出版された年が 2004 年ということもあり、前提が古くなっていることです。
印刷してコードリーディングしませんし（コンプラ的にもギリギリ）、 現代の IDE は高機能なので Java でそこまで悲惨な状況になったりしないと思いました。ただし、IDE の今後については割と当たっている部分があり、既に予期していたのは凄いと思いました。
C++における解説も何度かありましたが、Web プログラミングで C++を用いることはほとんどないので、言語の使用人口的にも対象読者がずれてきているのかなと思いました（組込み系はもちろん別です）。
オブジェクト指向的なリファクタリングで、継承による差分プログラミングを用いたリファクタリングが紹介されていました。
しかし、Effective Java でも「継承のための設計および文書化する、でなければ継承を禁止する」と記述されているので、リファクタリングのファーストチョイスには入らないと考えています。少なくとも、継承のつかいどきを熟知していなければ、やってはいけないと思いました。
2 つ目は、ある程度のオブジェクト指向の知識が前提になっていることです。
DI、継承、凝集度をあげる方法は Java または C++のオブジェクト指向の知識が前提になっていました。
これらがなければ理解が難しいと思いました。
近年では、モダンフロントエンド（React、Vue）や Go などのオブジェクト指向でない書き方が台頭しています。それらしか学んだことがない状態でこの本を読んでも、ソースコード的な面では得られるものが薄そうだと思いました。
次に関連で勉強すること
設計関連では以下の書籍を読もうと考えています。
