レガシーコード改善ガイド 保守開発のためのリファクタリング Object Oriented SELECTION

マイケル・C.フェザーズ【著】, ウルシステムズ【監訳】, 平澤章, 越智典子, 稲葉信之, 田村友彦, 小堀真義【訳】

• 販売会社／発売会社: 翔泳社
• 発売年月日: 2009/07/15
• JAN: 9784798116839

商品レビュー

2024/09/28

力作。手の施しようが無いようなレガシーコードに対する改善アプローチが体系的に整理されている。例題はJavaだが、ほとんどのプログラミング言語に適用可能だろう。本書を通じて、テスト(特に単体テスト)は本当に大事だと実感できた。

2021/04/25

いや〜。ものすごい大作だ。よくこの三部構成でうまくまとめたもんだ。
マイケルさんがかなり試行錯誤したのがうかがえるし、それでも読み解きづらくて一回読んだぐらいじゃわからないけど、それだけレガシーコードとの付き合い方が難しいということなんじゃないかなと。

誰でも自然と同じような手法を思いついて実践できているかもしれないけれど、名前をつけて体系的に整理し、
再現可能な状態にして効果を得られるようにしている。それに加え、よく相談される内容に沿ってそれらを
組み合わせて実践できるように整理してくれている。

一気通貫で読んだり、第二部第三部を行ったり来たりしながら読んだり、気に入った章、悩みにあうを読み返したり、
何度も読み返しながら実践していかないと、安全には理解、実践できないだろうなぁ。

テストを整備するための基本として、
単体でインスタンス化できること。
グローバル変数や static メソッドがないこと。
ネストが深すぎるとテストできない。
private メソッド群は別クラス/protectedにすべきでは？
というようなことが繰返し現れて、高凝集、疎結合にすることはもちろん、可視性を崩してでもテストしやすさを優先した方がいいという指摘は参考になる。

18章 スタブ、モック、フェイクの名前付けルールも試したい。

テスト可能な設計にするためには、
影響スケッチ(171ページ)
スケッチ(224ページ)
17章ストーリーを語る白紙CRC
20章 機能スケッチ
のような軽量ドキュメントも有益だが、それらを重視、メンテナンスしないのは
それが不要になるようなテスト、コードになっていくからなんだろう。

コンパイラ任せなどで自明な部分にまで執拗なテストを用意したり、仕様化が広範囲のEnd to Endなテストを
記載していたら、0.1秒の単体テストにはならないだろうから、そのあたりを拠り所にすると良さそうだけど、
どのようなまとまりが適切な粒度なのか、行き過ぎた分離なのかは明確な基準が見いだせていない。
ヒントは得られるものの絶対の解はなさそうだ。

新しい機能を作り上げる時よりも、レガシーコードを扱う時の方が設計スキルを発揮する機会ははるかに多くあります。 - 265ページ
隣の新規開発の芝は、実はそれほど青くありません。 - 336ページ

もうウンザリです。何も改善できません - 335ページ
と言いたくなるようなレガシーコードも多いけれど、この本を手元において2年ぐらい少しづつ改善しながら
付き合っていくことで、大半が自分のテリトリーになり、気づいたら設計スキルが磨かれていたというような
経験ができるんじゃないかなと思う。改善の旅はつづく。苦しみもあるが楽しんで乗り越えたい。

2021/03/28

遡って設計から改善するというより、設計を変えずにコードを改善することにフォーカスを当てていると思う。