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

買ってから数ヶ月経ってから読了。
読み始めてからは3週間ほどで読み終えることが出来た。

テストがないコードはレガシーコードだ!

という表紙の言葉はセンセーショナルであったし、まあ、そうなのかもな?って程度の認識だったんだけど、読み終える頃には違った感想を持った。
読む前は、理想論というか原則論というか、まあ、基本的にテストはあるべきだよね?って認識でしかなかったんだけど、多分そういうことじゃないんだと思う。
テストがあることにより、コード自体の構造が変わり、メンテナンスを行う上でのコストが大幅に下がる。
なので、テストがあるということは、それだけで「ある程度のレベルのコード」が担保されるということだと思う。
んー、文章にするとそのまんまなんだけど・・・あんまり上手く表現できてないな、けどまあ、そんな感じだ。

確かにテストがないコードは、より制約が少なくて品質もバラバラになる。
どれだけスキルがある人でも、テストをかかないと余程注意しないと安易な方向に逃げちゃったりすることもあるだろうしなあ。

この本は各章のタイトルが面白い。

同じコードをいたるところで変更しています

とか、

私のプロジェクトはオブジェクト指向ではありません

とか。
もう、すごいあるある一覧で、ニヤついてしまう。

決して建設的とも言えない愚痴のようなことをズラズラ並べて、読者の共感を得て気持ち良くさせて終わりようというものではなく、比較的現実的な解決策が並ぶ。
特に「テストは全部書かなくちゃ!」とこうあるべき論をドーンと並べていくというよりは、今日から出来る範囲でコツコツ改善していこう!という類の解決策が多いのが好印象。
プロジェクトメンバーやその周りのステークホルダーの皆さんが、きちっとテストを書く時間なんて担保してくれないことが多い現実を過ごしている自分としては、そういった姿勢で書かれていることが非常に嬉しいし、参考になるし、なんか凄く救われた。

以下、箇条書きで感想を並べる。

  • 仕様化テストもアリ(無いよりは全然良い)
  • コンストラクタでオブジェクトを生成する時は気をつけるべし
  • クラスやメソッド、出来れば変数名まで上手く名前が付けられないということは、ちゃんと理解し設計出来てない疑いがあるので注意(センスの問題じゃない気がする)
  • コードを解析する時は積極的に図を書いてみる
  • 試行リファクタリングはガンガンやろう(変にコードだけ読んで理解しようとせずに、動かした方が理解が進む)
  • シグネチャの維持などで、ある程度テストをサボるのもあり(改善の途中と捉える)
  • インターフェイス、抽象クラスなどをとにかく有効活用する
  • シングルトンパターンは諸刃の剣、使いどころに注意が必要
  • テストの為だけに必要なメソッドはあまり含めたくないけど、必要であれば受け入れる(現実的な選択)
  • 新規開発よりもレガシーコードにテストを作っていく方がスキルが必要(まあ、当たり前か)

とにかく完璧を求めすぎて、結局何もしないが一番まずいと思うので、長い目で見て少しでも改善されていくような視点は大切だなと思った。
そんな風に考えて行動している人ってどれだけいるんだろうか・・・。

こういった類の本は理想論で完結するものが多い気がするんだけど、この本に関していえば非常に現実的な解を提示してくれているのが凄くユニークだと思う。
オブジェクト指向なプログラミングを行う上で「テストしやすい」というのは、ポジティブな制約になってくれるはずなので、オブジェクト指向を勉強したい人にもおすすめな本。
かといって、メンテナンス性のことを考えれば、オブジェクト指向のあるべき制約を破ることも必要であれば行うべきという柔軟な姿勢も大切とこの本では謳っているけども。

とにかく、日ごろはレガシーコードをメンテナンスする人もたくさんいると思うので、そんな人たちへ勇気を与えてくれる貴重な本だと思う。
この本を日本語で読めたことに感謝。