いや〜。ものすごい大作だ。よくこの三部構成でうまくまとめたもんだ。 マイケルさんがかなり試行錯誤したのがうかがえるし、それでも読み解きづらくて一回読んだぐらいじゃわからないけど、それだけレガシーコードとの付き合い方が難しいということなんじゃないかなと。 誰でも自然と同じような手法を思いついて実践できているかもしれないけれど、名前をつけて体系的に整理し、 再現可能な状態にして効果を得られるようにしている。それに加え、よく相談される内容に沿ってそれらを 組み合わせて実践できるように整理してくれている。 一気通貫で読んだり、第二部第三部を行ったり来たりしながら読んだり、気に入った章、悩みにあうを読み返したり、 何度も読み返しながら実践していかないと、安全には理解、実践できないだろうなぁ。 テストを整備するための基本として、 単体でインスタンス化できること。 グローバル変数や static メソッドがないこと。 ネストが深すぎるとテストできない。 private メソッド群は別クラス/protectedにすべきでは？ というようなことが繰返し現れて、高凝集、疎結合にすることはもちろん、可視性を崩してでもテストしやすさを優先した方がいいという指摘は参考になる。 18章 スタブ、モック、フェイクの名前付けルールも試したい。 テスト可能な設計にするためには、 影響スケッチ(171ページ) スケッチ(224ページ) 17章ストーリーを語る白紙CRC 20章 機能スケッチ のような軽量ドキュメントも有益だが、それらを重視、メンテナンスしないのは それが不要になるようなテスト、コードになっていくからなんだろう。 コンパイラ任せなどで自明な部分にまで執拗なテストを用意したり、仕様化が広範囲のEnd to Endなテストを 記載していたら、0.1秒の単体テストにはならないだろうから、そのあたりを拠り所にすると良さそうだけど、 どのようなまとまりが適切な粒度なのか、行き過ぎた分離なのかは明確な基準が見いだせていない。 ヒントは得られるものの絶対の解はなさそうだ。 新しい機能を作り上げる時よりも、レガシーコードを扱う時の方が設計スキルを発揮する機会ははるかに多くあります。 - 265ページ 隣の新規開発の芝は、実はそれほど青くありません。 - 336ページ もうウンザリです。何も改善できません - 335ページ と言いたくなるようなレガシーコードも多いけれど、この本を手元において2年ぐらい少しづつ改善しながら 付き合っていくことで、大半が自分のテリトリーになり、気づいたら設計スキルが磨かれていたというような 経験ができるんじゃないかなと思う。改善の旅はつづく。苦しみもあるが楽しんで乗り越えたい。

『レガシーコードからの脱却』がレガシーコードを生み出さないプラクティス集であるのに対し、本書はレガシーコードと向き合うためのテクニック集である。 レガシーコード特有の様々な症状に対し、安全に少しずつリファクタリングしていく具体的な手順が説明されている。 サンプルコードは主にC++とJavaで書かれており、C++の知識がない読者にとっては読みにくいのと、全体的に説明が長ったらしい点はマイナスポイント。