この本を読みました。
紙の書籍の発売は、2016年11月のようです。
…知りませんでした。
本の装丁は、『レガシーコード改善ガイド』とそっくりです。
あれ、同じ本…？と一瞬思いましたが、違う本です。
レガシーコード改善ガイドも、とても面白い本なのですが、次々と新しい本を買ってしまう関係上、なかなか最後まで読めていません。
4月に購入しているのに、まだ半分ぐらい…
今回は、レガシーソフトウェア改善ガイドのほうの感想を書いていきます。
内容
古いソフトウェアの保守に苦しむ人向けに書かれた本だったな、と思います。
レガシーの定義（というか特徴）に関しては、本文中にありますが、イメージはこんな感じかと思います。
古くて、なんか怖くて触れないけど、動いちゃってる… 綺麗じゃないのはわかるんだけど、壊れるのが恐ろしくて触れない…
本番期と同じ環境無いから、新しいモジュールとか入れられないんだよ。 たまに、本番でソース動かしたら動かないことあるんだけど、環境無いから仕方ないよね。
ドキュメントが無いので尋ねたところ、「今のシステムの挙動が仕様です！」と言い切られた。 「この挙動は正しいんですか？」と尋ねたところ、「これバグですね」と言われる。（実話）
こういうソフトウェアを、そのまま保守し続けるのか、リファクタリングするのか、はたまたリライトするのか、という判断に関して、現実的な視点*1から書かれています。
それだけではなく、「リファクタリングの先へ」と題し、開発環境構築、テストや製品構築の自動化についてもたっぷり書かれています。
なお、ソース例や環境構築等は、基本的にJavaでの開発について書かれています。
レガシーソフトウェアに向かう人の心境
私も以前は、世に出てから10年以上は経つパッケージソフトの保守開発（ある法律に基づいたものであり、リリースは毎年やっていた）を担当しており、レガシーなソフトウェアと格闘していました。*2
また、クソシステムを継ぎ接ぎして作られた、更なるクソシステム*3のリライトも経験しています。
それらのプロジェクトでは、リファクタリングが許容されない環境でした。
…リライトの時も、同じ仕組みで書き換えろと言われましたが、アーキテクチャの変更もあったので、大幅に書き換えました。
私の経験が全てではないですが、レガシーと戦うときの心境はこんな感じかと思います。
- ゴミにぶつかって絶望する
- 書き換えたくてうずうずする
- でも知らないところを触るのは恐ろしい。担当もしたくない
- 担当外のところは責任もないし、知らない（ふりをする）*4
…ポジティブなものが全く出てきません。
書き換えられるなら、書き換えたい、というのが、正直な心境だと思います。
レガシーの改善
レガシーの改善には、リファクタリングとリライトがあります。
| 方法 | 説明 |
|---|---|
| リファクタリング | 既存の動きは変えず。コードを書き直す。コンポーネント分割等も含む |
| リライト | ソフトウェアを作り直す |
個々の説明等は本書を見ていただくとして。
たぶん、エンジニアならだれもが、リライトしたい！と考えると思います。
少なくとも、私はそうです。
しかし筆者は、リライトは基本的に悪い選択肢としています。
- 利用者にほとんどメリットがない
- もともとがバグだらけ
- 大抵時間を超過する
- アーキテクチャ的に不可能となるかもしれない
といったデメリットが大きく、大抵の場合、プロジェクトは大きく遅れるから、とのことです。
それでも、リライトしなければならない場合、というのはあるのですが…どういう時かは、本を読みましょう！
好きなフレーズ
本書に出てきた言葉のうち、印象的だったものを書いてみます。
その１
コードが対話処理を行うすべてのオブジェクトを、我々が制御できるオブジェクトで置き換えたい。
リファクタリングの、テストコード作成のところで出てきます。
本書では、テスト可能にするために、依存関係（WebやDB含む）から切り離された状態にする必要がある、ということです。
この考えは、プログラミングする上では絶対に必要だと思います。
むしろ、究極の目標と言ってもよいぐらいです。
全てを制御できれば、書き直しも理解も容易ですし、何より変化に強くなります。
その２
それぞれのサービスは、それ自身が持つドメインモデルにおける「コンテクスト境界」の役割を果たす。
これは、Webアプリケーション分散で、マイクロサービスを説明する際に出てきます。
私は、ドメイン駆動に関しては勉強してきたので、この説明は非常に理解しやすかったです。
「コンテクスト境界」というのは、「境界外のコンテクスト*5とは同じ用語があっても、全く別物として扱う」境界を指します。
境界外に、「ユーザー」とか「権限」という用語があったとしても、それは自身の境界内の「ユーザー」、「権限」とは別、として考えます。*6
その３
レガシーシステムを止められれば、データベースの完全な制御権を得られる。
これは、リライト時にデータベースをどうするのか、という部分で出てきます。
リライトに伴い、データベースの置き換えを行う場合、レガシーが止まるまでは、バッチ等での並行運用が必要です。
が、いずれ、レガシーが止まると、完全に自由に触れるようになります。
その日のために、良くない点、修正すべき点を全て記録しておけ！というときの言葉です。本当はもっと長いです。
例としては、カラム削除、型変更等です。
記録は大事。
レガシーなソフトウェアを触ったことない人は、幸せなのか不幸なのか…私にはわかりません。
しかし、現状に不満や疑問を持たないと、より良くしよう！という気持ちは出ないと思うので、一度ぐらいは触れていたほうが良い経験だとは思います。
その４
理想的には、開発者自身が、自分のローカルマシンに、すべての依存関係をインストールして実行できるようにすべきである。
これは、開発環境自動化の章で出てきます。
開発環境をローカルに持ってくることで、完全に自分の自由に触れる環境を作るべきだ！ということです。
開発環境の作成を、貧弱なテキストに書いて、それをメンテしていない、なんてことは珍しくないです。
私は、本当にただの手順である作業は、手順書を作るようにはしているのですが、さらに進んで
- 開発環境はREADMEに書いて、リポジトリの直下に置け！
- READMEに書いても多いなら、自動化しろ！
という記述に、私は反省しました。
まだまだ良いやり方があるのだと。それを探すことも大切だと。
なお、これによって、開発環境の自動化を行うと、製品環境構築の自動化につながっていき、いずれはDevOpsに…となっていくそうです。
おわりに
レガシーソフトウェアは、ただソースが汚い、というだけではないのだと、思い知りました。
考えてみたら、リファクタリングしないような保守的な環境は、開発環境、製品環境、構築環境等も、古いもの（一度構築したもの）を使い続ける傾向にあるように、私は感じます。
それらすべてを改善してこそ、レガシーソフトウェアの改善なのだと、理解しました。
本文ではほとんど触れませんでしたが、リファクタリングのやり方に関しても、ソースの書き方だけでなく、『達人プログラマー』を引用した「割れ窓理論*7」や、リファクタリングのやりすぎを防ぐ方法など、様々な観点から記載があり、とても分かりやすいです。
レガシーに苦しむ方は、読んでみるとヒントにはなるかもしれません。
