http://www.amazon.co.jp/gp/product/4798116831/mowanetjp-22
原著 "Working Effectively with Legacy Code" が出版されたのは2004年。5年間訳書が出なかったことによってただでさえ遅れている日本は更に5年遅れた。
本著のレガシーコードの定義は明確だ。
私にとって、レガシーコードとは、単にテストのないコードです。
本著が「レガシーコード」を「改善」する「ガイド」であれば、それはつまり「テストのないコード」を「改善」する「ガイド」という意味になる。Straightforward.
これは非常に重要なことだ。
つい最近私が手がけていた(そしてまだメンテナンスしている)コードにはテストがなく、効率は悪く、そして間違っていた。一方で、そのコードは本来の技術仕様外のケースをハンドルするコードがはっきりとif文で分岐する形でサポートされていおり、変に手をつければ今までサポートしていた何らかの例外ケースでリグレッションを起こすことは明らかだった。まさにこの本の言う「レガシーコード」であった。私がそのコードを1年ちかくかけて改善し続けた成果と同じ内容を、この本は包含しており、さらにそれより深い知見を与えている。
私が特定の項で「あれ、それだと不十分なんじゃ」と疑問を持つと、即座に次の項で「その通り、不十分なのです」とまるで私の心を読んでいるかのように応答してくる。そして、私の知見を越えた見解を示す。美しすぎる。
感嘆したのはそれだけではない。一つは、TDD (Test Driven Development) の項が8章にある点だ。
アジャイル開発手法の中で私が納得のいかないことの一つは、アジャイルを謳いながら、教育手段がアジャイル的でないことだ。TDDをまず最初に押し付けてくる。それでは誰も「失敗するテストから書き始める」ということの意味を納得出来ない。TDDの例は、アジャイルの教科書的なものでもお粗末であり、説得力にかける。そういう意味でアジャイル勢力はTDDの教育に置いてアジャイル的ではない。
この本は、「第8章 どうやって機能を追加すればよいのでしょうか？」でTDDを解説している。このタイミングは絶妙と言わざるを得ない。TDDが一番「すごい！」と思える(と少なくとも私が思っている)タイミングとぴったり一致する。このタイミングでの「失敗するテスト」とは機能追加に応じたテストだ。ゼロの状態で「失敗するテスト」を追加するよりはるかに利にかなって見える。「新機能を作りたい。その新機能とはこのテストを通るということだ。さぁ、TDDの時間だ」
この本は「レガシーコード」をリファクタリングすることに焦点を置く (ほとんどはテストが絡む)。そういう意味では『リファクタリング』 (http://www.amazon.co.jp/gp/product/4894712288/mowanetjp-22)があるが、同著がリファクタリングカタログ的で、正直読み通す気分にならないのに対して、この本は教科書的であり、読み通す必然性を感じさせる。ありとあらゆるリファクタリングパターンが、有機的に結合して「レガシーコード」に苦しむ人々の心を掴んで離さない。
評価は☆☆☆☆☆ (5)。文句なくMAXだ。
ただし難易度は実用方面で少し高め。実用コードで痛い目を見た人にお勧めで、そういう経験がないような学生にはあまりお薦めしない。先にじっくり基礎を温めるための本を読む方が良いだろう。
