パターン指向リファクタリング入門

パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法

『パターン指向リファクタリング入門』という、世間でそこそこ評判の良い本を買ってきてみた。リファクタリングするときにデザインパターンを取り入れましょう、っていう、まぁタイトル通りの本ですな。

これ、いい。すごく自然にパターンを導入できそうな感じ。

デザインパターンは、複雑になりがちな設計を洗練させるための奥義みたいなものなんだが、設計の最初からこれを取り入れるのは結構難しい。というのも、デザインパターンの適用が必要になるようなレベルの複雑さというのは、ソフトウェアを保守していく段階で生じることが多いからだ。

しかし、バージョンアップを重ねて設計が混沌化し、いまこそデザインパターンが必要だ！と思っても時すでに遅し。導入するにはあまりに修正箇所が多すぎるし、そもそも「動いているコードをさわるな」という古からの教えに縛られて手出し不能になる、というのがいつものパターン。

さて、リファクタリングは、ソフトウェアの中身を健全な状態に保つための手段である。コードから悪い臭いがした段階で、いい匂いがするようになるまでコードを刷新していくのだ。この際に懸念されるバグの混入は、あらかじめテストコードを書いて回帰テストすることで回避する。

つまり、ちゃんとリファクタリングできる環境を整えておけば、リファクタリングの一環としてデザインパターンを導入することができる。リファクタリングは必要になって初めて行う、つまりJust in TimeなのでYAGNIの原則を破ることも無い。

そんなわけで、デザインパターンとリファクタリングはとても相性が良いと思う。マーチン・ファウラーの『リファクタリング』でもパターンは少し触れていたのだが、『パターン指向リファクタリング入門』は、その箇所に特化した本となっている。これはオススメだね。デザインパターンを勉強したものの使いあぐねている人たちは是非読んで欲しい。

そうそう、技術面から話がそれるが、リファクタリングの必要性を説くためのメタファーとして『設計の負債』というものを提示しているのがなかなか面白い。

借金はさっさと返さないと延滞金が発生し、これがふくらみ、最後は返済不可能になり人生を破滅させる。設計もこれと同じで、開発を進めていく間にマズい設計（負債）が蓄積されていく（絶対にそうなる）。これをなるべく早くリファクタリング（返済）しなければ、その負債は雪だるま式にふくれあがって設計は混沌とし、ソフトウェアは保守不可能になり、早すぎる死を迎えることになる。

このメタファーで会社のお偉方を説得できている、と書いてあるのだが、そう簡単にいくもんかね？でも、なかなか説得力があると思うよ。