投稿元:
レビューを見る
自分のやり方は正しいんだなと、確認できるのはいいことです。
逆に、もっとうまいやり方があると指摘してもらうのも、とても大事。
そうやって、これまで感覚でやってたことが、体系だっていくんです。
この本を読むと、テストコードの整備とリファクタリングを、より確信を持って実践できるようになります。
リファレンスとしても役立つように、細かいテクニックを、カタログ的な形式で揃えてあります。
また、一つ一つに具体的な手順が示され、相互参照も充実しています。
システムを維持する必要があるなら、手許に置いておきたい本の一つです。
投稿元:
レビューを見る
他人の書いたコードを触った経験のある人には必読。
日本でレガシーコードというとVB、COBOL、FORTRANなどで、本書で扱われるC++やJavaはそういう認識が無いのだろうが、具体的なノウハウもさることながら一般概念を拾い読みするだけでも腑に落ちるところが多い。
投稿元:
レビューを見る
表紙にある通り、「テストがないコード」を「レガシーコード」と定義し、以下にテスト可能な状態に変えていくかを、これでもかと詰め込んだ一冊。
本書のすごいところは、コードの変更の仕方だけでなく、「影響スケッチ」などを用いたアナログな手法でのコード解析や、レガシーコードと戦う際の心構えなど、ありとあらゆるテクニックを解説していることです。
ともするとコードだけに注目しがちですが、レガシーコードと戦うには総合的な力が必要なのだと、改めて認識しました。
また、本書では「テスト可能なコード」であることが第一で、きれいな設計などはそのあとに考えればいいと言っています(かなり乱暴に要約してます)。これは、テストが可能であれば、安心してリファクタリングが行えるため、まずはテストを用意しようという考えからです。このことも、従来の「修正が容易な設計」を目指していた方法とは違いますが、より現実に即しているとも感じました。
まずは本書を開き、そのテクニックを日々のプログラミングに活用してみてください。私は「レガシーコードの改善」だけでなく、TDDで進めていくにあたって、どうやってテストを書いたらいいのか参考にしました。
本書は、すべてのプログラマーにお勧めできる一冊です。
投稿元:
レビューを見る
レガシーコードをいかにHackしてテストケースの作成やリファクタリングを行うかの本。
JavaやC++はともかくCでリンカを変えて本番コードからテスト用のモックを参照するというのは目から鱗でした。
既に存在するレガシーコードに対してのアプローチを前提に書かれているため大抵の現場で役に立つと思われますw(サンプルコードはJava/C++/Cが中心だけど別言語でもたぶん置き換えは可能)
リファクタリングに伴う影響の調査
↓
本番コードをテストコードで保護&本番コードに依存性を注入しテストしやすくする
↓
本番コードを修正
といった石橋を叩きすぎて渡るというポリシーが素敵。プロなら品質を担保するためにこれくらいやるべきですよねw
ただし内容は非常に難しいので、最低でも「リファクタリング プログラムの体質改善テクニック」や「クリーンコード」を読んでいることが前提かと。
http://booklog.jp/users/sue445/archives/4894712288
http://booklog.jp/users/sue445/archives/4048676881
読み終わった本の中で仕事中にもすぐ手にとりたい物は机の上に立てているのですが、この本は表紙の「テストがないコードはレガシーコードだ!」が非常にショッキングなため机の上にみんなに表紙が見えるように置いていますw
投稿元:
レビューを見る
リファクタリングの素晴らしさを理解したあと自分の職場で実践しようにも、非常にコードが古くて断念した人にオススメの本。
テストの書かれていないコードをレガシーコードと定義し、全くテストされていないコードをどのようにテストクラスを書いていくのか、どのようにリファクタリングしていくのかを実践的に書いてある。
この本のお陰で、Fortranのコードに対してテストを書く勇気が湧いた。
投稿元:
レビューを見る
本書が、腑に落ちるところの多い良書であることは、他所のレビュで明らかであるが。個人的に、まさに今問題に感じていることが指摘されていたため、感動すら覚えた。
私の目に触れるところの運用の現場では、なんの保証もない、「慎重な手順」だけを頼りに保守をつづけて、度々失敗を繰り返している。彼らはコード変更を忌み嫌い、誰もリファクタリングしようとは考えず、ただ「前例教」の原理主義を貫いている。
彼らには是非この本を読んでリファクタリングとテストコードの重要性を理解し、今の状態がいかに狂気に満ちているのか気付いて欲しい。
ある人は『狂気とは、同じことを繰り返しながら、違う結果を望むこと』であると言ったという。彼らは今まさにそんな状態である。
投稿元:
レビューを見る
2ヶ月前に途中まで書いたコードの続きを最近覚えたTDDでと思ったら、テストするためにはリファクタリングが必要で、リファクタリングにはテストが必要でとデッドロックしたので読んだ。
リファクタリング発展編。アンチパターン的な。でも人ごとではなく身の回りで常に見かける現実なのでお役立ち度は高い。自動テストがない状態のコードをどのようにテスト可能、リファクタリング可能な状態に持っていくか。テストのないコードを変更することが如何に大変かの例をこれでもかと見せられることでテストの重要性をヒシヒシと感じる本。サンプルはJava7割、C/C++3割。
自動テストがあれば素早いフィードバックが得られる。すると、間違いにすぐに気づいて手戻りが減る、デグレードを起こさない安心が得られる。直接的な効果だけでなく、対象コードについての記憶が残っているうちに対処できるので思い出す手間が不要だし、手動確認による繰り返し作業がなくなって退屈しないし、何より結果がすぐ出て頻繁に達成感が得られるのは楽しい、と良いこと尽くめ。
最近はJMockitとかのモックフレームワークでバイトコードから差し替えられるのでレガシーコードのジレンマは当時ほどではないのかもしれない。
投稿元:
レビューを見る
これも単体テストをちゃんと書けるようになってから読むべきだった。
いろいろ勉強しようとあせりすぎて、順番を見失っていた感がある。
投稿元:
レビューを見る
テストがないコード=レガシーコードと定義して、既存のコードに対してテストを書きやすいようにするべきことをまとめた一冊。
リファクタリングの知識がないと読み解くのは難しいかな。副読書として「リファクタリング」を読まれることをおすすめします。
リファクタリングの知識をフル導入して、既存のコードをどうやって変更してテストしやすいように改善するかが本書のポイント。
JavaとC++のコード例が大半なのですが、C++をほとんど忘れかけている自分にとってはC++の部分は読むの辛かったなぁ。例の都合上、C++でないといけないものもあったんだけど、Javaにできなかったかなぁと思う部分もあったので、☆は4つで。
投稿元:
レビューを見る
オブジェクト指向やデザパタの理想的な設計じゃなくて、現場の状態を加味したうえで、コードをテストで守れるを目指すのは現実的だと感じた。
また試行的リファクタリングによる設計理解や影響スケッチってのは新しい業務になったときに使えそうだと思った。
C/C++の勉強にもなったかな。
理解できず読み飛ばしてしまったところもあるのでまたどこかのタイミングで読み直したい
投稿元:
レビューを見る
ケースごとにトピックで構成されており、リファレンス的にも今後も使えると思う。期待していた通りの内容と質だったと思う。
リファクタリングする基準などピンと来るところが多々あり、記載されているサンプルコードがすごい參考になった。
レガシーコードとは書き方や構成の古さではなく、テストのないコードと言っているところがすごい!
テストがあればコードを変更するリスクと手間が省けるということは認識しているので、自分もどんどんテストを書いていこうと改めて認識できた。
投稿元:
レビューを見る
自分が必要としていたのはまさしくこの様な本かも知れない。
単体テストの無いレガシーコードをどうやって安全に改修していくのか、具体例とともにさまざまな手法を提示してくれる。
投稿元:
レビューを見る
Object Mentor社のマイケル・C・フェザーズによる、単体テストを書きながら進めることによりレガシーコードを改善していくための解説書である。
本書ではレガシーコードを「テストのないコード」と言い切っている。
本書は「テストのないコードは、最初はきれいに書かれていても、場当たり的な機能追加により、時間につれ汚いコードになっていく。そして影響分析ができないため、どんどんコードの変更が恐ろしくなる」という心が痛くなる指摘で始まっている。
レガシーコードに対する機能追加・変更の際に、部分的に依存関係を排除したテストコードを書きながらコーディングを行うことによって、最終的にテストが完備された「安全に改変出来るコード」を目指している。
テスト駆動開発の書籍は多いが、すでにある (テストのない) コードを改善していくというその実用的な数々の手法には感心させられる。非常に実用的な1冊でおすすめだが、翔泳社にありがちな、書籍サイズが大きいのが不満。
投稿元:
レビューを見る
レガシーコードと戦う人のためのバイブルというべき一冊。読みながら、「あ、こういう手があったか!」と思わず膝を叩いてしまうことが多く、非常に勉強になった。
文中のコード例のほとんどは、Java、C++だが、未経験者でも他のオブジェクト指向言語を齧っていれば、だいたい理解できるのではないかと思う。
どうしていいか分からないコードの前で頭を抱えているプログラマに知恵と勇気を与えてくれる。オススメです。
投稿元:
レビューを見る
(まだ読書途中です)
良い設計=継続開発に柔軟に対応出来る設計
悪い設計=些細な変更で腐敗してしまう設計
この本では、
後者の設計を改善する方法を提案しているようです。