リファクタリング

プログラミングスタイル

プログラミングをするスタイルには以下の二つがあります。

１．行き当たりバッタリのプログラミング
　　できるところから、思いつくところから、思いつくままに進めて試行錯誤しながらやっていき、共通化できるところをメソッド、クラスにしていく。

２．クラス・メソッドのの構造をあらかじめきちんと設計してから行う。

優秀なプログラマはすべて２のタイプで、１は初心者だと思っている人が結構います。しかし、実際には優秀なプログラマでも１のタイプの人は結構います。パッと思いついたことをダーッと書き、それを修正して、結果としてきちんとしたクラス構造ができているといった感じです。ある程度経験のあることなら、頭の中に設計図があるので、それに沿ってプログラムを書き、外部にクラス設計などを書くことはありません。

最初にきちんと設計をしたつもりでも、実装段階では想定したとおりに行かなかったり、抜けがあったりすることはよくあることです。案ずるよりは生むが易しで、実際に書いているうちにいろいろ思いつくこともあります。

とはいえ、このアプローチだと、ソースがつぎはぎだらけになる可能性もあります。ちょこっと例外的な処理を付け加えて、を繰り返し、コードは汚くなっていきます。そうしてソースがスパゲッティ化し、メンテ不能のソースとなっていきます。

そうならないようにするためにリファクタリングがあります。リファクタリングとは、仕様を変えることなく、ソースコードを改造することをいいます。汚いソースコードでもプログラムは動きますが、メンテナンスするのは大変です。汚いソースコードと綺麗なソースコードではメンテのしやすさが全く違います。なのできるだけ綺麗なソースを書くように心がけ、汚くなったら速やかに書き直すことです。後々のことを考えて、わかりやすいソースに直します。

ただ、その都度リファクタリングしていけばいいのですが、面倒くさいと思うと、そのままにしてしまったりします。また、ある程度出来上がったものに対する修正は、根本から直すことにもなり、その手間ひまを考えると難しいものです。

動いているソースには手を加えない？

一般に、現在動いているコードは、すでにテスト済みで、動作が保証されているため、「動いているソースには手を加えるな」と言われています。これはもっともなことです。多くの人が、動いているソースに安易に手を加えて痛い目にあった経験があることでしょう。「何でかよくわからないけど動いているからまあいいや」なんて言葉も聞かれ、まさに触らぬ神にたたりなしで、下手なことはしない方がいい場合があります。

ですので、改修や追加開発で、ソースコードをいじらなければならない場合は、修正箇所を限定して、その影響範囲を明確にします。修正箇所がわかるようにコメントをつけて、それ以外に直したい箇所があっても、正常に動作している限りはいじらないことです。特に既存のソースを別の人・別の会社が作成し、改修案件に自分が参加している場合、余計な責任を被らないためにも、手を触れないことです。私もしばしば改修案件で一から作り直したいと思うようなひどいソースに出合ったことがあり、既存の潜在バグも十分ありそう、というか、あるものでしたが、そこには手を触れず、修正要件に関わる部分だけをいじり、インデントや行末のスペースさえも変えないようにしたものです。

一般的にはこれが現実的な選択肢です。

テストの自動化

もしリファクタリングを行うのであれば、必須なのがテストの自動化です。これなくしては、リファクタリングは現実的ではありません。ソースコードを大幅に改造したとき、既存の機能が正しく動作するのかをいちいち手動で全部確認するのは、手間とコストがかかります。

テストを自動化しておくと、短時間で動作が確認できるので、大胆にソースを改造していくことも可能です。

ただしです。これは、そのテストが全項目を網羅している場合です。もし自動化しているテストに抜けがあるなら、そのテストをパスしたとしても、バグが潜んでいる可能性は十分にあります。修正前のテストの一部を手動で行っていたり、あるいはたまたま動いていたような場合、注意する必要があります。

実際他人の作ったテストケースや、あるいは自分で作った場合でも、記憶が薄れるような昔に作ったようなテストケースは信用なりません。完全に仕様を理解しているなら、テストケースが網羅できているかどうかチェックできますが、既存のプロジェクトでは、仕様のすべてはドキュメント化されておらず、あるいはドキュメントに嘘が含まれており、テストケースが完全であるかどうかをチェックするのは難しいものです。

なので、自動化されているからといって妄信しないことです。一方、自分で新規に開発を行っている場合は、テストケースすべてを網羅するようにして、どんどんリファクタリングを行っていくべきでしょう。

設計の重要性−−リファクタリングには時間がかかる

大規模なリファクタリングには時間がかかります。テストの自動化をしていても時間がかかります。アプリケーションのアーキテクチャを変更するようなことが後でないように、できる限り想定できる範囲まできちんと設計しておきます。特に業務アプリケーションのような、似たような処理をたくさん作り、しかもそれぞれ形式を統一しなければならないような場合、後でアーキテクチャーを変更すると修正はかなり大変になります。単純置換できる場合はいいですが、手作業となると膨大な時間がかかります。

テストの自動化をしなくても

リファクタリングについてバイブル的な存在は、マーチン・ファウラの「Refactoring: Improving the Design of Existing Code」（リファクタリング―プログラムの体質改善テクニック）という本です。

テストの自動化をしなくても、リファクタリング、というよりも、綺麗なソースコードの書き方として、この本に書いてあることは知識として知っておいて損はないでしょう。というよりも、プログラマであれば当然知っているべきことです。

なので、私は、この本はプログラマ必読の書と考えています。

この本は非常によくできた本で、多くのサイトで取り上げられています。私もこのページで、いろいろ解説しようかと思いましたが、すでに優れたサイトがあるので、このページでは、個人的な備忘録としてメモ書きを連ねていきます。

参考になるサイトは、Googleで「リファクタリング」「refactoring」で検索すればたくさん出てきます。特に気になったのは以下のサイトです。

Refactoring Home Page
　　リファクタリングのホームページで、新たなリファクタリングカタログも追加されています。

リファクタリング勉強ノート
　　最初のリファクタリングの例のソースコードがダウンロードできるようになっていて、解説もされています。

SmellsToRefactorings

Smells to Refactorings Quick Reference Guide

また以下の本も、よくまとまっています。

プログラムの育てかた 現場で使えるリファクタリング入門

私は実は本は持っていません。日本語版も読んでいません。原書はWeb上からpdfでダウンロードできるので、それを読みました。以前、ブログで紹介したところはリンクが切れているようでしたが、以下からダウンロードできます。

この本でのポイントの一つは、一度にリファクタリングをしないということ。徐々に行っていくことです。このステップの解説がページを増やしていっています。

リファクタリングの手順は、既存のものはそのまま残し、置き換えるものを追加し、最後に既存のものを削除します。ただしこれは一気にやってもよく、もしバグが起きたときは、小さなステップを順々に行っていきます。

このカタログの中では、相反するものが出てきます。例えばExtract MethodとInline Methodは、一方はメソッドの抽出であり、もう一方は、メソッドを削除して呼び出し側に直接処理を書くというもので相反しています。これは、どちらが常に正しいというのではなく、状況に応じて適切に行うことが大切であるということを示しています。

http://mirrors.cn99.com/books/Refactoring.pdf

言語はＣですが、以下のサイトも綺麗なソースを書くための参考になります。

Ｃプログラミング診断室--うつくしく健康なプログラムのために

「Refactoring: Improving the Design of Existing Code」メモ書き

When Should You Refactor?

Tip
Three strikes and you refactor.

 Refactor When You Add Function
 Refactor When You Need to Fix a Bug
 Refactor As You Do a Code Review

・  Programs that are hard to read are hard to modify.
・  Programs that have duplicated logic are hard to modify.
・  Programs that require additional behavior that requires you to
change running code are hard to modify.
・  Programs with complex conditional logic are hard to modify.

Chapter 3. Bad Smells in Code

A a = o.getA();
B b = a.getB();
C c = b.getC();

Chapter 6. Composing Methods

double basePrice = anOrder.basePrice();
return (basePrice > 1000)
 　↓
return (anOrder.basePrice() > 1000)

Chapter 7. Moving Features Between Objects

Chapter 8. Organizing Data

 return Collections.unmodifiableSet(_courses);

Chapter 9. Simplifying Conditional Expressions

  if (onVacation() && lengthOfService() > 10) return 1;
  else return 0.5;

  return (onVacation() && lengthOfService() > 10) ? 1 : 0.5;

double getPayAmount() {
	double result;
	if (_isDead) result = deadAmount();
	else {
		if (_isSeparated) result = separatedAmount();
		else {
			if (_isRetired) result = retiredAmount();
			else result = normalPayAmount();
		};
	}
	return result;
};

double getPayAmount() {
	if (_isDead) return deadAmount();
	if (_isSeparated) return separatedAmount();
	if (_isRetired) return retiredAmount();
	return normalPayAmount();
};

 if (customer == null) plan = BillingPlan.basic();
 else plan = customer.getPlan();
    ↓
 plan = customer.getPlan();

interface Null {}

class NullCustomer extends Customer implements Null...

aCustomer instanceof Null

Chapter 10. Making Method Calls Simpler

void setValue (String name, int value) {
  if (name.equals("height"))
    _height = value;
  if (name.equals("width"))
    _width = value;
}
 ↓
void setHeight(int arg) {
  _height = arg;
}
void setWidth (int arg) {
  _width = arg;
}

Chapter 11. Dealing with Generalization

Chapter 12. Big Refactorings