レガシーコード改善ガイド (Object Oriented SELECTION)

  • 翔泳社
4.27
  • (49)
  • (42)
  • (11)
  • (3)
  • (1)
本棚登録 : 792
レビュー : 41
  • Amazon.co.jp ・本 (472ページ)
  • / ISBN・EAN: 9784798116839

作品紹介・あらすじ

システム保守の現場でありがちな、構造が複雑で理解できないようなコードに対する分析手法・対処方法について解説。コードを理解し、テストできるようにし、リファクタリングを可能にし、機能を追加できるテクニックを紹介。

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • 本書が、腑に落ちるところの多い良書であることは、他所のレビュで明らかであるが。個人的に、まさに今問題に感じていることが指摘されていたため、感動すら覚えた。
    私の目に触れるところの運用の現場では、なんの保証もない、「慎重な手順」だけを頼りに保守をつづけて、度々失敗を繰り返している。彼らはコード変更を忌み嫌い、誰もリファクタリングしようとは考えず、ただ「前例教」の原理主義を貫いている。
    彼らには是非この本を読んでリファクタリングとテストコードの重要性を理解し、今の状態がいかに狂気に満ちているのか気付いて欲しい。
    ある人は『狂気とは、同じことを繰り返しながら、違う結果を望むこと』であると言ったという。彼らは今まさにそんな状態である。

  • 表紙にある通り、「テストがないコード」を「レガシーコード」と定義し、以下にテスト可能な状態に変えていくかを、これでもかと詰め込んだ一冊。
    本書のすごいところは、コードの変更の仕方だけでなく、「影響スケッチ」などを用いたアナログな手法でのコード解析や、レガシーコードと戦う際の心構えなど、ありとあらゆるテクニックを解説していることです。
    ともするとコードだけに注目しがちですが、レガシーコードと戦うには総合的な力が必要なのだと、改めて認識しました。
    また、本書では「テスト可能なコード」であることが第一で、きれいな設計などはそのあとに考えればいいと言っています(かなり乱暴に要約してます)。これは、テストが可能であれば、安心してリファクタリングが行えるため、まずはテストを用意しようという考えからです。このことも、従来の「修正が容易な設計」を目指していた方法とは違いますが、より現実に即しているとも感じました。
    まずは本書を開き、そのテクニックを日々のプログラミングに活用してみてください。私は「レガシーコードの改善」だけでなく、TDDで進めていくにあたって、どうやってテストを書いたらいいのか参考にしました。
    本書は、すべてのプログラマーにお勧めできる一冊です。

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

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

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


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

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

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

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


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

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

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


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

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

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

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


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

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

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

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

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

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

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

  • オブジェクト指向やデザパタの理想的な設計じゃなくて、現場の状態を加味したうえで、コードをテストで守れるを目指すのは現実的だと感じた。
    また試行的リファクタリングによる設計理解や影響スケッチってのは新しい業務になったときに使えそうだと思った。
    C/C++の勉強にもなったかな。
    理解できず読み飛ばしてしまったところもあるのでまたどこかのタイミングで読み直したい

  • 自分のやり方は正しいんだなと、確認できるのはいいことです。
    逆に、もっとうまいやり方があると指摘してもらうのも、とても大事。
    そうやって、これまで感覚でやってたことが、体系だっていくんです。

    この本を読むと、テストコードの整備とリファクタリングを、より確信を持って実践できるようになります。

    リファレンスとしても役立つように、細かいテクニックを、カタログ的な形式で揃えてあります。
    また、一つ一つに具体的な手順が示され、相互参照も充実しています。

    システムを維持する必要があるなら、手許に置いておきたい本の一つです。

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

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

  • ノウハウ集。

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

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

全41件中 1 - 10件を表示

マイケル・C・フェザーズの作品

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
David Fl...
スティーブ マコ...
Joel Spo...
ブライアンカーニ...
Travis S...
ケント ベック
ケント・ベック
有効な右矢印 無効な右矢印

レガシーコード改善ガイド (Object Oriented SELECTION)を本棚に登録しているひと

ツイートする
×