15 人中、14人の方が、｢このレビューが参考になった｣と投票しています。
5つ星のうち 5.0
設計が悪いシステムの保守でお悩みの方へ, 2006/2/7
レビュー対象商品: Working Effectively With Legacy Code (ペーパーバック)
レガシーコードの定義ですが以下のようになります。
ーーー
レガシーコード =
テストできない、していない、設計に問題があるようなコード
ーーー
つまり、どんなに最近に構築されたとしても上記の定義にあてはまるものはレガシーコードです。
本書は、このレガシーコードを
どうやって修正、機能追加を行っていくのか
どうやって既存の設計を改善していくのか
ということが記述されています。
java, c++, c が対象となっています。（javaの扱いが一番多いです）
本書の目次をちょっとみてみると、レガシーコードで悩んでいる方は
興味を持たずにはいられません。以下は目次を一部抜粋しました。
○My Project is not object oriented. How do I make safe changes?
○I need to change a Monster Method and I can't write test for it.
保守担当以外の方でもレガシーコードに対する解決策を学ぶことで、新規開発の際に自分がレガシーコードを書かかずに済みますので、将来的な勉強にもなります。
実際に、設計が悪いシステムの保守をしています。
しかし。この本のおかげでやる気になり良いシステムにどうしたら変えていけるのか？ということを実践できるようになりました。設計の勉強にもなっています
作者の頑張れという気持ちが伝わってくる大変な良書です。
設計が悪いシステムの保守に悩んでいたら本書を手にとってみてください。
きっとシステムを改善していけるようになるでしょう。
1 人中、1人の方が、｢このレビューが参考になった｣と投票しています。
5つ星のうち 4.0
Realistic Guide Book on "How to Inject Unit Test into Legacy Code", 2011/3/18
レビュー対象商品: Working Effectively With Legacy Code (ペーパーバック)
本書では「レガシーコードとは テストのないコードのことだ」と簡潔に定義します。この定義のうえで、
「それでもレガシーコードを変更・拡張しなければならない! どうすればいい?」
という現実的な問題に取り組みます。
コードの変更を 安全に行うには テストが必要です。しかし レガシーコードにテストを書くのは 容易ではありません。それは依存性のせいです (クラスのコンストラクタが ネットワークやDBを必要とするなど)。これがレガシーコードのジレンマです。
The Legacy Code Dilemma
When we change code, we should have tests in place. To put tests in place, we often
have to change code.
本書の主なテーマは、レガシーコードに対してテストを書くことです。そのために、テストなしでも安全に行える 構造変更 (保守的なリファクタリング) を行います。このとき使うテクニックが dependency-breaking technique です。本書の第25章は、約90ページを使って 様々な dependency-breaking technique を紹介しています。
それ以外の章では、以下のようなことが書かれています。
・どの dependency-breaking technique を どんなときに使うか
・絡まったレガシーコードを理解するには どんな図を描いたらいいか
・アーキテクチャの概要をうまく説明する/してもらうには どんな方法があるか
ユニットテストを書きたいけど 書けない! どうしたらいい?
と思っている人におすすめです。
typoが散見されるので 星4つ。
