Page4ちょっとそこのお客さん。浮かない顔をしていますね。それはおめでとうございます。ユーザー・インターフェイスはすごく格好よいのに、ソース・コードがぐちゃぐちゃで何が何やら分からないと。それなのに、評価の高いソフトだからと機能追加の要求がいくつも発生していると。何が何やら分からないソース・コードを修正して、その要求に対応しなければならないわけですか。やれといわれても、できるわけがない。ははぁ、時間をかけて書き直したとしても、その書き換えが正しいのか自信が持てないと。どこか、思いも寄らないところで書き換えの悪影響が出るのではないかと心配されているのですな。そんなお客さんに、とっておきの良いものを紹介しましょう。リファクタリングというものなんですがね。いまならお安くしておきますよ。最近、プログラム開発技法などの話題で、「リファクタリング」という言葉をしばしば見掛けることがある。エクストリーム・プログラミング(XP)やテスト駆動開発においては必須の手法として取り上げられるが、それらの一部というわけではなく、単独で話題になる場合もある。リファクタリングとは何かに関しては、十分に理解されていなかったり、誤解されていたりすることが多いようである。そこで、本稿ではあらためてリファクタリングの基本中の基本を解説し、「リファクタリングって何?」という疑問に対して答えることを試みてみたい。プログラミングの体質改善テクニック』(ピアソン・エデュケーション刊)に示されている。この書籍がリファクタリングという言葉を使った最初のものではないようだが、リファクタリングに関する集大成としてバイブル的に扱われており、リファクタリングとは何かを考えるよりどころにこの書籍を持ってくることは間違いではないと思う。この書籍は読みやすく、しかもこの短い記事よりもはるかに詳細であるから、「この本を読め。以上!」と書いて終わりにしてもよいぐらいである。この記事をここに書いてみたい。Basicプログラマにはなじみにくいということにある。.NETで示しつつ話を進めたい。前置きはそれぐらいにして、本題に入ろう。そもそも、リファクタリングとは何だろうか。上記書籍の副題「プログラミングの体質改善テクニック」というのがその答えになるだろう。プログラミングの体質改善といわれても、ピンとこない読者も多いだろう。そもそも、プログラミングに体質などというものがあるのだろうか。あったとして、それは改善できるものなのだろうか。ここでは、イメージしにくいプログラミングの「体質」という言葉は忘れて、もっとざっくばらんに分かりやすい言葉で語る方がよいだろう。それが冒頭の文章である。手に負えない汚いソース・コードに対処できる画期的なテクニックがリファクタリングということである。−POINT−リファクタリングは手に負えない汚いソース・コードに対処することができるテクニックでは、自分はいつもきれいなコードを書くことを心掛けているからリファクタリングは必要ない、と思ってよいかというと、そうではない。どんなにきれいなソース・コードを書こうと心掛けていても、修正を加え続けると、いつかは手に負えない汚いソース・コードに堕落してしまうケースが多いためである。手に負えなくなってからリファクタリングを実施するという選択もあるが、それよりも、手に負えなくなる前に汚さの萌芽を摘み取ってしまう方が楽である。複雑怪奇にソース・コードが絡まり合う前に、問題が起こりそうな個所を刈り取ってしまうのである。そのような刈り取りにもリファクタリングは利用できる。−POINT−リファクタリングは手に負えない汚いソース・コードに堕落しないために使用することができるテクニック以上のような話から、もう一度、リファクタリングの目的を考えてみよう。リファクタリングの目的は直接的には手に負えない汚いソース・コードに対処することではあるが、もちろんそれが最終目的ではない。汚いソース・コードに対処する力を得ることは、プログラミングの苦労を軽減することにつながる。プログラマは楽ができる。作業が楽になれば、より短い時間で完了できる。プログラミングの生産性が向上するわけである。故に、以下のようにいい直すことも可能だろう。−POINT−リファクタリングはプログラマが楽をするためのテクニック−POINT−リファクタリングは生産性を改善するためのテクニック■理解できないソース・コードを扱うことはできるか?さて、ここまでの説明で、いくつも「本当か?」「ウソくさい」と思える話が出てきたと思う。筆者が思い付く範囲内にあるそれらの疑問については、できるだけここで1つ1つ説明を加えていきたいと思う。ここでは抽象的な説明で、単にリファクタリングするなら知らなくてもよいことを語る。面倒だと思ったら、ここは読み飛ばしても構わない。後述している具体的なリファクタリング・カタログの紹介から先に読んで、釈然としなかった場合に戻ってきて読んでもよい。読み方は読者の自由である。これは当然の疑問といえる。このようなソース・コードは、最初から書き直した方が早いと評価されることも多い。ソース・コードを理解するために時間を費やすぐらいなら、同じものをゼロから書いた方が早い、という意見である。このような主張が正しい事例は、経験的にいくつもある。経験的に正しい対処方法の1つといってよかろう。リファクタリングはその正しい経験則に逆らう主張をしているかのように見えるはずだ。経験則の逆転などということが可能なのだろうか?もうちょっと具体的に、この疑問を説明しよう。クラスやモジュールを記述する場合(よほど行き当たりばったりでもない限り)、それらには「役割」が与えられている。在庫管理クラスを作ったのならば、そのクラスは在庫管理の機能だけを含めるべきであって、給与計算の機能を含めるのは正しい選択ではない。そのようなソース・コードは、プログラマを混乱させるだけである。給与計算のコードを調べるために在庫管理クラスを見る必要があるなどとは誰も思わないだろうし、在庫管理のコードを調べているところに、いきなり給与計算のコードが出てきては在庫管理を理解する妨げになる。Principle)」という用語もある。このように考えると、理解できないソース・コードとは、それぞれのクラスやモジュールが持っている「役割」が理解できないソース・コードということになる。在庫管理の機能をいくつかのクラスやモジュールによって処理していたとしよう。それは判断できるわけがない、と考えるのが妥当な態度だろう。判断できない状態で、エイヤッと適当にコードを追加すれば、ソース・コードの理解不能度はさらにレベルアップしてしまう。どのクラスやモジュールに存在するかという根拠がない機能が増えるためである。それだけならまだしも、理解できないソース・コードに機能を追加しても、それが正常に動作するか、誰も保証できないのである。これでは、とても胸を張って「手に負えない汚いソース・コードに対処した」とはいえない。ここまで読み進んだ読者で、そろそろこの記事を読むのをやめようかと思った方がいるかもしれない。リファクタリングなどという実用のテクニックが存在するとは信じられない気持ちになっていると思うからだ。リファクタリングは実在していて、しかもその有用性が経験的に確かめられているテクニックである。このギャップはどこからくるのだろうか。これに答えることは、人によっては天動説から地動説に置き換わるほど大きな驚きとなるかもしれない。この答えを決して認めたくない、というプログラマも、読者の中にはいるかもしれない。逆に、なんだそんな当たり前のことかと平然と受け止める読者もきっといるだろう。■理解できないソース・コードを扱うことができる理由では「理解できないソース・コードを扱うことはできるか?」という問いに対する答を書こう。それは「可能」である。その理由は次のとおりである。−POINT−ソース・コードには理解せずとも扱える部分が存在するといっても、何が何やらさっぱり分からないだろう。実際に、理解できないソース・コードを扱う簡単な事例を紹介しよう。以下は、とあるモジュールの、とあるメソッドの一部である。これを、フラグ変数を使わない形に書き換えることができるだろうか(ちなみに、この書き換えは、リファクタリングでは「制御フラグの除去」と呼ばれる)。とあるモジュールの、とあるメソッドの一部このコードをフラグ用の変数「flag」を使わない形に書き換えることができるだろうか。これは、さほど難しい話ではないだろう。以下のように書き換えられる。リスト1のコードをフラグを使わない形に書き換えたものさて、この書き換えを行うために、このコードを含むメソッドの機能や、メソッドを含むクラスの役割を理解している必要はない。筆者としては、このコードがどのような役割を持っているかを読者に伝えてはいないが、それでも書き換えは可能だろう。読者が上記コードの役割が分からないのは筆者がそれを伝えなかったからだ。これがソース・コードが手に負えないほど汚いケースでも「役割がよく分からない」という状況は同じである。すれば、このような書き換えを、そのような汚いソース・コードにも適用できるはずだ。理解できないソース・コードを扱うことはできるのである。7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。TranslatorはPowerPoint用のアドイン。