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

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

2018/08/07

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

2018/05/20

テストのないコードはレガシーコード、どれだけいいコードであろうとテストがない状態では変更するのが非常に困難になる。
接合部(seam)を作り、接合先をモックにする。
古いコードはまず仕様化テスト(Characterization test)やってみる

2017/04/16

本書は、レガシーコード（遺産のような古いコード）を改善する際の心得やノウハウをまとめた本である。

まず前提として、どんなコードも時間と共に劣化していく、という事実がある。
どんなに綺麗に書かれ、どんなにシンプルなアーキテクチャを持ち、どんなに素晴らしいエンジニアが保守していても、機能を追加していくうちにコードは肥大化し、複雑になっていまうことは避けられない。

だからこそ必要なのは、コードを劣化させないことではなく、古くなったコードを巻き戻す技術である。
それがリファクタリングであり、本書で解説する肝である。

では、リファクタリングのやり方はどうすべきなのだろうか。

まず一つのやり方として「書いて祈る」。
つまりバグを出さないように細心の周囲を払いながら、慎重に慎重に編集するという方法がある。

注意深く作業することは、一見プロらしいやり方かもしれない。
しかしいくら気をつけたからといって、それに比例して安全性が上がっていくのだろうか。

もちろんそうではない。
ソフトウェアは複雑であり、どれだけ気をつけても、バグを埋め込まないように全てを把握することは現実的に不可能である。
よって本当に大切なのは、精神論ではなく、バグが出なくなるような手法・ツールを取り入れることである。

正しいリファクタリングの手順としては、まず最初にテストコードを書くことから始める。
そして挙動を「固定」した後にコードの修正に取りかかれば、安全に作業できる。
レガシーコードにおいて大切なのは、「どう動くべきか」の前に、「今どう動いているのか」を把握することである。

わざわざ今動いてるものに対してテストを書くのは、一見非効率に思えるかもしれない。
しかしテストを自動化しないと、何か変更をする度に手動でテストをしなければならなくなり、より大きなコストがかかってしまう。

自動化した方が結果的に開発工数が短縮できることは、過去に多くのプログラマが体験しているはずである。

他には、リファクタリングのポイントとして、ネーミングの価値についても取り上げられている。

メソッド名やクラス名に優れた名前がついていれば、それはシステムの理解を大きく助けてくれる。
逆に貧弱な名前がついていれば、後から来るプログラマはつらい日々を送ることになってしまう。
よって、適切な名前をつけることはとても重要である。

特にクラス名の変更は、最も強力なリファクタリングである。
名前が変わることで見え方が変わり、新たな可能性に気づくことが出来るようになるからである。

またネーミングの議論は、ぜひチーム全体でやった方がよい。
それはチームに、システムがどう動くべきかという共通認識をもたらしてくれる。

本書はプログラマ界隈で名著と呼ばれることも多く、勉強のために読んでみた。

だが残念ながら、内容が古いというか、現代では当たり前になっていることも多く、得たものはあまり多くなかった。
分量のわりにはさほど勉強にならなかった、というのが正直な感想である。

しかし、逆に言えばそれだけ普遍的なことが書かれているということである。
プログラマで未読の方は、一度読んでおいて損はないかもしれない。

2015/09/27

http://kimikimi714.hatenablog.com/entry/2015/03/13/200000
書いた

2015/03/26

Object Mentor社のマイケル・C・フェザーズによる、単体テストを書きながら進めることによりレガシーコードを改善していくための解説書である。

本書ではレガシーコードを「テストのないコード」と言い切っている。

本書は「テストのないコードは、最初はきれいに書かれていても、場当たり的な機能追加により、時間につれ汚いコードになっていく。そして影響分析ができないため、どんどんコードの変更が恐ろしくなる」という心が痛くなる指摘で始まっている。

レガシーコードに対する機能追加・変更の際に、部分的に依存関係を排除したテストコードを書きながらコーディングを行うことによって、最終的にテストが完備された「安全に改変出来るコード」を目指している。
テスト駆動開発の書籍は多いが、すでにある (テストのない) コードを改善していくというその実用的な数々の手法には感心させられる。非常に実用的な1冊でおすすめだが、翔泳社にありがちな、書籍サイズが大きいのが不満。

2014/01/07

『リファクタリング』の実践版と言って良い．
システム開発の半分以上は新規開発ではなく既存モジュールへの機能追加・改善であることを念頭に，そのソース修正を安全に行うには，というのが本書の目的．
で，その方法として「テストを書いて保護する」という方法を挙げて，そのために「いかにテスタブルなプログラムに改善するか」を解説するのが本書．
もちろん，レガシーコードをテスタブルに改善する作業を知ることで，自分のコーディング力アップにもつながるわけで．
ある程度の実務経験があれば行ったことのある作業を，あらためて明確な目的のもとに体系化して解説されることで，頭のなかの整理になるので読んでよかったと思う．

2013/11/24

（自動）テストコードの存在しない「既存」プログラムに対して、テストコードを書けるようにする方法（主にプログラム間の依存性を減らす）について述べた本

では逆に「新規」プログラムを作成する際に、依存性が少なく、テストコードを書き易い状態を保つにはどうすれば良いかが知りたい場合は、下記の本が参考になるので、合わせて読むと良いと思う
「実践テスト駆動開発　−テストに導かれてオブジェクト指向ソフトウェアを育てる」

2013/07/22

テストがないコード（レガシーコード）はテストを書こうと思ってもそう簡単にはいかない。この本ではそんなときに役立つTipsが書かれています。継承を使うスマートな方法から、簡単なメモを書こうという泥臭い方法まで幅広く書かれていて面白かったです。

最後のTips「レガシーコードで成功する鍵は、やりがいを見出すこと」からは、世の中の多くの人もレガシーコードに立ち向かっているんだなあと元気をもらえました。

2013/06/21

やらなければいけないと思っていたテストコードの作成。
だけども具体的にどうやって書けば良いのか解らず本書を手にとった。とても良い内容で何から手をつければ良いのかが解った。仕様化テスト、書いていこう。

2013/03/27

(まだ読書途中です)

良い設計＝継続開発に柔軟に対応出来る設計
悪い設計＝些細な変更で腐敗してしまう設計

この本では、
後者の設計を改善する方法を提案しているようです。