- Amazon.co.jp ・本 (449ページ)
- / ISBN・EAN: 9784798116839
作品紹介・あらすじ
システム保守の現場でありがちな、構造が複雑で理解できないようなコードに対する分析手法・対処方法について解説。コードを理解し、テストできるようにし、リファクタリングを可能にし、機能を追加できるテクニックを紹介。
感想・レビュー・書評
-
いや〜。ものすごい大作だ。よくこの三部構成でうまくまとめたもんだ。
マイケルさんがかなり試行錯誤したのがうかがえるし、それでも読み解きづらくて一回読んだぐらいじゃわからないけど、それだけレガシーコードとの付き合い方が難しいということなんじゃないかなと。
誰でも自然と同じような手法を思いついて実践できているかもしれないけれど、名前をつけて体系的に整理し、
再現可能な状態にして効果を得られるようにしている。それに加え、よく相談される内容に沿ってそれらを
組み合わせて実践できるように整理してくれている。
一気通貫で読んだり、第二部第三部を行ったり来たりしながら読んだり、気に入った章、悩みにあうを読み返したり、
何度も読み返しながら実践していかないと、安全には理解、実践できないだろうなぁ。
テストを整備するための基本として、
単体でインスタンス化できること。
グローバル変数や static メソッドがないこと。
ネストが深すぎるとテストできない。
private メソッド群は別クラス/protectedにすべきでは?
というようなことが繰返し現れて、高凝集、疎結合にすることはもちろん、可視性を崩してでもテストしやすさを優先した方がいいという指摘は参考になる。
18章 スタブ、モック、フェイクの名前付けルールも試したい。
テスト可能な設計にするためには、
影響スケッチ(171ページ)
スケッチ(224ページ)
17章ストーリーを語る白紙CRC
20章 機能スケッチ
のような軽量ドキュメントも有益だが、それらを重視、メンテナンスしないのは
それが不要になるようなテスト、コードになっていくからなんだろう。
コンパイラ任せなどで自明な部分にまで執拗なテストを用意したり、仕様化が広範囲のEnd to Endなテストを
記載していたら、0.1秒の単体テストにはならないだろうから、そのあたりを拠り所にすると良さそうだけど、
どのようなまとまりが適切な粒度なのか、行き過ぎた分離なのかは明確な基準が見いだせていない。
ヒントは得られるものの絶対の解はなさそうだ。
新しい機能を作り上げる時よりも、レガシーコードを扱う時の方が設計スキルを発揮する機会ははるかに多くあります。 - 265ページ
隣の新規開発の芝は、実はそれほど青くありません。 - 336ページ
もうウンザリです。何も改善できません - 335ページ
と言いたくなるようなレガシーコードも多いけれど、この本を手元において2年ぐらい少しづつ改善しながら
付き合っていくことで、大半が自分のテリトリーになり、気づいたら設計スキルが磨かれていたというような
経験ができるんじゃないかなと思う。改善の旅はつづく。苦しみもあるが楽しんで乗り越えたい。詳細をみるコメント0件をすべて表示 -
本書が、腑に落ちるところの多い良書であることは、他所のレビュで明らかであるが。個人的に、まさに今問題に感じていることが指摘されていたため、感動すら覚えた。
私の目に触れるところの運用の現場では、なんの保証もない、「慎重な手順」だけを頼りに保守をつづけて、度々失敗を繰り返している。彼らはコード変更を忌み嫌い、誰もリファクタリングしようとは考えず、ただ「前例教」の原理主義を貫いている。
彼らには是非この本を読んでリファクタリングとテストコードの重要性を理解し、今の状態がいかに狂気に満ちているのか気付いて欲しい。
ある人は『狂気とは、同じことを繰り返しながら、違う結果を望むこと』であると言ったという。彼らは今まさにそんな状態である。 -
表紙にある通り、「テストがないコード」を「レガシーコード」と定義し、以下にテスト可能な状態に変えていくかを、これでもかと詰め込んだ一冊。
本書のすごいところは、コードの変更の仕方だけでなく、「影響スケッチ」などを用いたアナログな手法でのコード解析や、レガシーコードと戦う際の心構えなど、ありとあらゆるテクニックを解説していることです。
ともするとコードだけに注目しがちですが、レガシーコードと戦うには総合的な力が必要なのだと、改めて認識しました。
また、本書では「テスト可能なコード」であることが第一で、きれいな設計などはそのあとに考えればいいと言っています(かなり乱暴に要約してます)。これは、テストが可能であれば、安心してリファクタリングが行えるため、まずはテストを用意しようという考えからです。このことも、従来の「修正が容易な設計」を目指していた方法とは違いますが、より現実に即しているとも感じました。
まずは本書を開き、そのテクニックを日々のプログラミングに活用してみてください。私は「レガシーコードの改善」だけでなく、TDDで進めていくにあたって、どうやってテストを書いたらいいのか参考にしました。
本書は、すべてのプログラマーにお勧めできる一冊です。 -
本書は、レガシーコード(遺産のような古いコード)を改善する際の心得やノウハウをまとめた本である。
まず前提として、どんなコードも時間と共に劣化していく、という事実がある。
どんなに綺麗に書かれ、どんなにシンプルなアーキテクチャを持ち、どんなに素晴らしいエンジニアが保守していても、機能を追加していくうちにコードは肥大化し、複雑になっていまうことは避けられない。
だからこそ必要なのは、コードを劣化させないことではなく、古くなったコードを巻き戻す技術である。
それがリファクタリングであり、本書で解説する肝である。
では、リファクタリングのやり方はどうすべきなのだろうか。
まず一つのやり方として「書いて祈る」。
つまりバグを出さないように細心の周囲を払いながら、慎重に慎重に編集するという方法がある。
注意深く作業することは、一見プロらしいやり方かもしれない。
しかしいくら気をつけたからといって、それに比例して安全性が上がっていくのだろうか。
もちろんそうではない。
ソフトウェアは複雑であり、どれだけ気をつけても、バグを埋め込まないように全てを把握することは現実的に不可能である。
よって本当に大切なのは、精神論ではなく、バグが出なくなるような手法・ツールを取り入れることである。
正しいリファクタリングの手順としては、まず最初にテストコードを書くことから始める。
そして挙動を「固定」した後にコードの修正に取りかかれば、安全に作業できる。
レガシーコードにおいて大切なのは、「どう動くべきか」の前に、「今どう動いているのか」を把握することである。
わざわざ今動いてるものに対してテストを書くのは、一見非効率に思えるかもしれない。
しかしテストを自動化しないと、何か変更をする度に手動でテストをしなければならなくなり、より大きなコストがかかってしまう。
自動化した方が結果的に開発工数が短縮できることは、過去に多くのプログラマが体験しているはずである。
他には、リファクタリングのポイントとして、ネーミングの価値についても取り上げられている。
メソッド名やクラス名に優れた名前がついていれば、それはシステムの理解を大きく助けてくれる。
逆に貧弱な名前がついていれば、後から来るプログラマはつらい日々を送ることになってしまう。
よって、適切な名前をつけることはとても重要である。
特にクラス名の変更は、最も強力なリファクタリングである。
名前が変わることで見え方が変わり、新たな可能性に気づくことが出来るようになるからである。
またネーミングの議論は、ぜひチーム全体でやった方がよい。
それはチームに、システムがどう動くべきかという共通認識をもたらしてくれる。
本書はプログラマ界隈で名著と呼ばれることも多く、勉強のために読んでみた。
だが残念ながら、内容が古いというか、現代では当たり前になっていることも多く、得たものはあまり多くなかった。
分量のわりにはさほど勉強にならなかった、というのが正直な感想である。
しかし、逆に言えばそれだけ普遍的なことが書かれているということである。
プログラマで未読の方は、一度読んでおいて損はないかもしれない。 -
Object Mentor社のマイケル・C・フェザーズによる、単体テストを書きながら進めることによりレガシーコードを改善していくための解説書である。
本書ではレガシーコードを「テストのないコード」と言い切っている。
本書は「テストのないコードは、最初はきれいに書かれていても、場当たり的な機能追加により、時間につれ汚いコードになっていく。そして影響分析ができないため、どんどんコードの変更が恐ろしくなる」という心が痛くなる指摘で始まっている。
レガシーコードに対する機能追加・変更の際に、部分的に依存関係を排除したテストコードを書きながらコーディングを行うことによって、最終的にテストが完備された「安全に改変出来るコード」を目指している。
テスト駆動開発の書籍は多いが、すでにある (テストのない) コードを改善していくというその実用的な数々の手法には感心させられる。非常に実用的な1冊でおすすめだが、翔泳社にありがちな、書籍サイズが大きいのが不満。 -
オブジェクト指向やデザパタの理想的な設計じゃなくて、現場の状態を加味したうえで、コードをテストで守れるを目指すのは現実的だと感じた。
また試行的リファクタリングによる設計理解や影響スケッチってのは新しい業務になったときに使えそうだと思った。
C/C++の勉強にもなったかな。
理解できず読み飛ばしてしまったところもあるのでまたどこかのタイミングで読み直したい -
自分のやり方は正しいんだなと、確認できるのはいいことです。
逆に、もっとうまいやり方があると指摘してもらうのも、とても大事。
そうやって、これまで感覚でやってたことが、体系だっていくんです。
この本を読むと、テストコードの整備とリファクタリングを、より確信を持って実践できるようになります。
リファレンスとしても役立つように、細かいテクニックを、カタログ的な形式で揃えてあります。
また、一つ一つに具体的な手順が示され、相互参照も充実しています。
システムを維持する必要があるなら、手許に置いておきたい本の一つです。 -
遡って設計から改善するというより、設計を変えずにコードを改善することにフォーカスを当てていると思う。
-
『レガシーコードからの脱却』がレガシーコードを生み出さないプラクティス集であるのに対し、本書はレガシーコードと向き合うためのテクニック集である。
レガシーコード特有の様々な症状に対し、安全に少しずつリファクタリングしていく具体的な手順が説明されている。
サンプルコードは主にC++とJavaで書かれており、C++の知識がない読者にとっては読みにくいのと、全体的に説明が長ったらしい点はマイナスポイント。 -
リファクタリングについて体系的に整理されているため、今のコードは何が問題なんだっけ?その問題はどうすれば解決できるんだっけ?ってところを考えながら読むと良さそう。
そういう意味では、チーム内での輪読と相性が良さそうかな。
逆に言えば現実のコードへの実践へ繋げずにただ読んでも「なるほどー」程度で終わってしまいそうな印象。