リファクタリング―プログラムの体質改善テクニック読んだ

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史
出版社/メーカー: ピアソンエデュケーション
発売日: 2000/05
メディア: 単行本
購入: 94人クリック: 3,091回
この商品を含むブログ (307件) を見る

残念ながらピアソン桐原から出版されていたので、現在は手に入りにくいんだけど、読んだ。

内容的には、リファクタリング手法のカタログみたいな感じだと思う。５章くらいまでは、導入とか、リファクタリングの心構えみたいな事が書いてある。

リファクタリングをするときに「いつすべきか？」というのが問題になると思うんだけど、この本では、機能を実装するときにその周辺をリファクタリングするといいと書いてあった。これは「動いてるものは触るな」っていう考え方と「実装とリファクタリングは対になるべきだ」という事だと理解した。

人間は最初から完璧な設計など出来ないし、開発が進むにつれて最初は適切な設計だったものが、そうではなくなる事もある。そのためにリファクタリングを行って、適切な設計をなるべく保つというような事が書いてあった。

糞コードと戦うために、リファクタリングとデザインパターンを学ばなければ殺されてしまうと思って読み始めたんだけど、最後まで読んだ感想としては「最低限の教養がある人間が書いたコードが対象」「時間の経過などによって、コードに不吉な臭いがしてきた場合のリファクタリングカタログ」という感じだった。

今やってるプロジェクトは、炎上の火消しに投入されたんだけど、凄く酷いコードの巣窟になっている。例をあげると切りがないが、Singletonっていう名前の（本当にSingletonって名前だった）Singletonなクラスがpublicな連想配列を持っていたりする。

聞いた話によるとプロジェクトのスタートからヤバくて、プログラミング初めて半年そこらの人間が２人アサインされて、コードレビューなども無しに開発が進んでいたそうだ。その時に、手本として提供されたコードが下記のような感じで、書いた人の話を聞くと「ファサードパターンを適用した」らしい。

↓こんなの

class App {
  public static App getInstance();
  public Object sharedObject(String className, name);
}

コード自体はJavaっぽく書いた擬似コードなので、なんとなく雰囲気だけ伝わればという感じなんだけど、Appっていうクラス名で（本当にAppって名前だった）、クラス名とそのオブジェクトにつける名前を渡すと、そのクラスのインスタンスを作ってくれて、すでに同名のインスタンスをAppが作ったことがあったらそれを返す、という感じ。凄く簡単に言うと、グローバルな連想配列にオブジェクト突っ込みまくれる状態。

これを体験して、プロジェクト開始時の設計などコードの品質に関するハンドリングと、コードレビューの重要さを再認識した。また、デザインパターンは教養のない人間*1が教養*2感覚で学んではいけないとも感じた。

僕はGoFの概要をざっくりと把握している程度で、デザインパターンをまともに学んでいないのだけど、デザインパターンは必要になるまで学ぶべきでないと思っている。それは、Factoryの名前を冠したゴミクラスや、上記の"ファサード"や、Singletonをグローバル変数として用いたコードに、デザインパターンの詳細を知る以前に苦しめられた経験からそう思っている。だけど、適切な教育を受けた人間は、必要になる前から教養としてデザインパターンを学んでも問題ないのかもしれない。

ただ、設計はとても重要だし、レビューなどで悪い設計を指摘するときに相手に伝わる言葉で説明できなければならない。それもあって、この本を読んだ。次はデザインパターン本を読もうと思っている。

そんな感じで関係ないことも書いたけど、この本はいい本だったと思う。悪しきピアソン桐原によって現在はほぼ手に入らなくなってしまったけど、代替となる本は色々と出てると思う。

設計などに関連する書籍は殆ど読んだこと無いんだけど、リーダブルコードは良書だったと思う。プログラムは人間のために書くものだという意識が芽生える。