オージス総研の本 [リファクタリング：プログラムの体質改善テクニック]

リファクタリング：プログラムの体質改善テクニック

マーチン・ファウラー著
児玉公信友野晶夫平澤章梅澤真史訳
株式会社ピアソン・エデュケーション 5,040円　（税抜き 4,800円）
ISBN4-89471-228-8

	『本書に寄せて』より
	『目次』より
	『訳者あとがき』より

『本書に寄せて』より

「リファクタリング」はSmalltalkerの間で生まれました。しかし、他のプログラミング言語のコミュニティで受け入れられるのにそう長くはかかりませんでした。リファクタリングはフレームワークの開発に不可欠な考え方なので、「フレームワーク設計者」が自らの技法について語るときに、その言葉が自然に口をついて出てくることになったからです。クラス階層を洗練しているときや、コードを何行削減できるかを熱く語っているときに、何度も「リファクタリング」と口にすることになりました。優れたフレームワーク設計者は、フレームワークが最初から正しいものにはならないことを知っています。それは経験を重ねて進化していくものだからです。また、コードを書くよりも、読んで修正することの方が多いということもわかっています。リファクタリングは、コードを読みやすくして、修正しやすいものに保つための鍵なのです。これは特にフレームワークにおいて言えることですが、ソフトウェア一般にも当てはまります。
しかし、ここで問題となることがあります。リファクタリングはリスクが高いのです。現在動作しているコードを変更しなければならず、それが新たなバグを引き起こすかもしれません。リファクタリングは、やり方を間違えると何日もの手戻りになりますし、何週間にも及んでしまうこともあります。さらにリファクタリングは手順を守らず、やみくもに行われた場合に最も危険となります。コードを軽く修正するつもりで始めたのに、新たに変更すべきところが判明して深みにはまっていきます。コードを修正するほど問題がわき起こり、次々と変更しなければならなくなります。そして、ついには脱出できないほどの大穴を自らコードにあけてしまうのです。こうしたことを避けるために、リファクタリングは体系的に行わなければなりません。私が仲間とともに「デザインパターン」の本を書いたときには、デザインパターンはリファクタリングの目標を提供すると述べました。しかし、目標を特定するというのは問題の一部に過ぎません。すなわち、コードをそこに近づけるように変換していく作業は、また別の課題なのです。
Martin Fowler（および共著者の方々）は、このリファクタリング作業に焦点を当てることで、オブジェクト指向ソフトウェア開発に多大な貢献をしたといえます。本書では、リファクタリングの経験則が述べられ、コードを改善するために、いつ、どのようにリファクタリングを行うべきかを解説してあります。本書の核となっているのはリファクタリングの包括的なカタログです。各リファクタリングでは、優れたコードへ変換していくための動機と手順が詳しく述べられています。中には「メソッドの抽出」や「フィールドの移動」のように当たり前と思えるものもあります。しかし、侮ってはいけません。正しい手順の理解は、秩序を保ったままでリファクタリングを行うのに不可欠なことです。本書のリファクタリングをマスターすれば、小さなステップでコードを変更していくことができるようになります。これによって、設計を改善する際のリスクを軽減できます。急いでこれらのリファクタリングとその名前を、開発用の語彙に加えましょう。
私自身がこの秩序だった「1度に1ステップずつ」のリファクタリングを経験したのは、Kent Beckと30,000フィートの高地訳注1でペア・プログラミング訳注2をしていたときです。彼は、本書にあるリファクタリングの手順が実際に行われていることを示してくれました。私はこの実践的な方式が、いかに役立つかに驚かされました。修正されるコードに自信を持てるようになっただけでなく、ストレスを感じなくなりました。さあ、リファクタリングをぜひ実施してみてください。コードも、それを書いたあなた自身も健康になれることでしょう。

『目次』より

『訳者あとがき』より

Gofデザインパターンは分析から設計に移る際の悩みに対し、問題に対する解決策という形で道筋を示します。一方リファクタリングは、実装において設計を振り返り、既存の機能を保ちつつコードをよりよい設計へと進化させていく手順を述べたものです。
このフォワードとリバースの流れが一体となることで、初めてスムーズなスパイラル開発が可能になります。繰り返し型プロセスで開発されるチームの皆さん、デザインパターンに加え、ぜひ本書の手法を試してみてください。また、この本では実装レベルでのコード例が豊富に載っているため、実装を受け持つことの多い初心者プログラマの方にもわかりやすい内容になっています。まずコードのりファクタリングから設計の世界を知り、分析へとスキルアップしていくための書でもあるわけです。いざ、ラウンドトリップの旅へ。Bon Voyage!

乱れた既存のコードを修正するための「リファクタリング」という言葉をはじめて聞いたときは、この業界ではよくある、しばらくすると消えてしまう新種の流行語ぐらいに思ったものでした。しかし実際にこの本を読んでみると、非常に実践的、かつ地道なノウハウ集でした。
この本を読んでみながら、私がまだ新入社員だった当時に「テストが終わったら、もうそのコードには触るな」と先輩から教えられたことを何度も思い返しました。確かに人間のやることには間違いが付き物ですし、ましてや他人の書いたコードを大幅に書き換えるのには勇気が要るものです。そして、その言葉がずっと引っかかっていたために、ただ読み易くする目的で、動いているコードを手直しするような時には、何となく後ろめたい気がしたものでした。
そんな私にとって、この本は（少々オーバーな表現ですが）コペルニクス的回転とも言えるのでした。何しろ「コードが動いた後でも設計判断が間違っていたと思ったなら、いつでもリファクタリングをすればよい」のですから。そして「完璧な事前設計をする必要がない」ことも「コメントを書くよりも、コメントが不要なコードに変更すべき」ことも、あらためて言われると目から鱗が落ちる内容でした。
Fowler氏には、「アナリシスパターン」と「UMLモデリングのエッセンス」を通じて、ずいぶんと目から鱗を取ってもらいましたが、今回もまたまたお世話になってしまいました。

あとがきでこんなことを書くのもどうかと思うのですが。
リファクタリングの適用可能性には十分な注意を払う必要があります。この技法は、依然としてリアルタイム系、分散系、データベースのように状態の変化に敏感なソフトウェアにつきものの再現性の低いバグを混入しえます。驚きましたか。驚く必要はありません。そのことに注意してこの技法を使えばよいと思います。
なんで、こんなことを冒頭に述べさせていただいたかというと、どんなものにも適用可能な範囲があることを意識していただきたいからです。この技法と密接な関係にあるXPが海の向こうでは大流行だそうです。それこそ、XPがあれば後は何もいらないというほどの勢いと聞いております。そういえば、そんな話はこれまでに何度もありましたね。UNIXがあれば、Windowsがあれば、構造化があれば、オブジェクト指向があれば、Smalltalkがあれば、C++があれば、Javaがあれば、デザインパターンがあれば、ウォーターフォールがあれば。そして、それらのものは、次のものが現れたときに忘れられてしまいます。それぞれには、適用可能な範囲があります。どれも、そこにはまれば素晴らしい効果を発揮する技術です。
私は、リファクタリングという技法がいつか忘れ去られてもよいものとは思いません。それは、本書に書かれたことが本当の実を結ぶためにも必要なことと思います。だから、今は、あえて私の中のリファクタリングに対する熱狂を表現せずにおきます。
さて、本書は、アーキテクトの方にこそ読んでもらいたい一冊です。オブジェクト指向開発方法論でシステムを構築しようとするときに陥りやすい罠があります。私は、本書でそれに気付きました。「柔軟性」の扱いです。アーキテクトの方には、本書を予測に基づく「柔軟性」に対する判断として読んでいただきたい。私は、何とこのことに無意識であったかを思い知らされました。
ところで、リファクタリングは、パターンの一種であると考えられます。本書に書かれていないリファクタリングを日本の皆さんが見つけられることもあろうと思います。そんなとき、臆さず語り合えたらよいですね。

ちょうど、アナリシスパターンを訳し終わった頃（1997年12月）にリファクタリングという言葉を聞きました。すでに、Fowlerさんのホームページにその言葉があったように思います。実はそれ以前に、GoFのTemplate Methodパターンと第６章に出ていたのですが、恥ずかしいことに、この本で指摘されるまで、それに気がつきませんでした。
リファクタリングという言葉は、ファクタリングを繰り返すという意味ですが、このファクタリングという語が構造化分析設計の世界にもあります。それは単一の機能のみを含むようにモジュールを分割し、同じ機能を重複させないようにすること（Page-Jones,1980,1988）とされています。これが、このリファクタリングの語源であるとは言いきれませんが、欧米のオブジェクト指向技術者には、こうした知識背景があるのだろうと感じました。
リファクタリングにおいて重要な技術は、いうまでもなくテストの自動化ですが、この他にも明言されていない基礎技術が必要だと思います。それは、ソフトウェア構成管理（SCM）で、CMM、ではレベル２のキープロセスエリアになっています。コードをダイナミックに変更させて行くならこれは必須なのですが、実はなかなか運用は難しいようです。これも、わが国の技術背景の浅いところではないかと思っています。
さて、Fowlerさんは、アナリシスパターンという上流の分析技術から、UMLの使い方、そしてリファクタリングと、非常に幅広い実績を持っておられます。これらの著書を読むと、その知識や経験がOdellやBeckを含むすばらしいコミュニティに支えられていることがわかります。こういう環境も非常にうらやましく思うところです。本書は、平澤さん、梅澤さん、友野さんと私の４人で翻訳しました。実は、この４人はパターンのコミュニティ（JapanPLoP ; https://www.kame-net.com/jplop）のメンバなのです。このように訳書が出版できてみると、わが国にも、こういうすばらしいコミュニティができつつのだと、あらためて感じました。