レガシーコード改善ガイド の商品レビュー

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

2021/04/25

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

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

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

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

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

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

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

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

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

2021/03/28

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

2020/04/29

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

2019/11/20

リファクタリングについて体系的に整理されているため、今のコードは何が問題なんだっけ？その問題はどうすれば解決できるんだっけ？ってところを考えながら読むと良さそう。
そういう意味では、チーム内での輪読と相性が良さそうかな。
逆に言えば現実のコードへの実践へ繋げずにただ読んでも「なるほどー」程度で終わってしまいそうな印象。

2019/01/20

いまごろこれ読むのは周回遅れ感あるけど、会社での読書会にかこつけて。

自戒を込めて、いくつか引用。
「隣の新規開発の芝は、実はそれほど青くありません。」
「レガシーコードを扱うのは手術と同じであり、1人で手術を行う外科医はいません。」
「良い設計はテスト可能であり、テスト可能でない設計は悪い設計である、ということは常に真実です。」

2019/01/17

TDDの代表的な本は、かなり冗長な内容で退屈だったが、この本は以下の点でとてもコンパクトにまとまっている。

・テストがないシステムをレガシーシステムと定義し、テスト対応させるノウハウを通じて、「なぜテストが重要か」という事を理解させている。

・巻末にノウハウをまとめてあるので、後から参照しやすい

Javaや.NETだけではなく、非オブジェクト指向言語や、C++での方法論の記載も良い

2018/11/22

いい設計ならテストが書けるテストが書けないコードはいい設計ではない、といったモットーの本。サンプルコードの言語は古いが参考になりました。昔読んだマーティンファウラーのリファクタリングとの関連を思いながら読みました。

2018/10/23

なんと、この本買ったのは、２年と３か月前。買ったことすら忘れてたが、現在レガシーコードを相手にしていて、Amazonでその対策本探したら、この本を発見。Amazonの「 お客様は、2011/3/10にこの商品を注文しました。」メッセージに助けられ、２冊目を買わずに済んだ。この本の定義では、・レガシーコードとは、UTの無いコード・レガシーコードとは、きれいか、汚いかとは関係ないなので、この本のターゲットは、「UTの無いコードにUTを入れる」方法。サンプル（java, C++)が豊富かつ、UTの差し込み方法も詳細に解説。よく書かれていると思う。

2018/10/07

テストコードのないコードは「レガシーコード」である。 という素晴らしい定義をして、世の中に氾濫するレガシーコードを如何にメンテナンス可能なコードにしていくか、をまとめた本。 いわゆるリファクタリング本だけど、最近出た本なので内容が先進的かつ実践的でよい。

2018/08/07

レガシーコードにユニットテストを仕掛けるパターンとして、かなり価値の高い情報が綴られている。が、内容や言い回しが学術的で、導入の手引きとしては扱いづらい。
どんな人が読むのが適切なのかギモン。レガシーコードが目の前にあるプログラマーは、たぶんレガシーコードを生み出すような組織文化の中にいるので、ユニットテストできる構造がどういうものかを知らないし、リファクタリングの知識も薄いと考えられる。すると、知らないことを把握するには、この本の説明は平易ではない。
知ってる人が理論として造詣を深めるために読むのが良さそうだが、その割には細かく具体的すぎる。