BOOK Preview Code Complete 第2版　上・下 ― 完全なプログラミングを目指して ― 第24章 リファクタリング マイクロソフトプレスの書籍紹介ページ 書籍情報のページ 2005/05/10

Page1 Page2 Page3 Page4 Page5 Page6

24.5 リファクタリング戦略

　どのようなプログラムでも、効果的なリファクタリングの数はほぼ無限にある。他のプログラミング作業と同様に、リファクタリングも収益逓減の法則の対象となり、「80対20の法則」が適用される。利益の80%をもたらす20%のリファクタリングに時間を使うべきである。どのリファクタリングが最も重要なのかを判断する際には、次のガイドラインを検討する。

■ ルーチンを追加するときにリファクタリングする
　ルーチンを追加する際には、関連するルーチンがうまく構成されているかどうかを確認する。そうでなければ、それらをリファクタリングする。

■ クラスを追加するときにリファクタリングする
　クラスを追加すると、既存のコードの問題が明らかになることがよくある。この機会に、追加したクラスと関係の深いクラスをリファクタリングする。

■ エラーを修正するときにリファクタリングする
　バグの修正から得た知識を基に、似たようなエラーが発生しそうなコードを改善する。

■ エラーが発生しやすいモジュールに的を絞る
　モジュールによっては、他よりもエラーが起きやすく、脆弱なものがある。コードの中にチームの全員が不安に思っている部分があれば、おそらくその場所はエラーが発生しやすいモジュールである。ほとんどの人は、このような面倒なコードを避けてしまいがちだが、これらの部分をリファクタリングの対象にすることは、きわめて効果的な戦略の1つである（Jones 2000）。

参照 エラーが発生しやすいコードについては、第22章の「22.4.1 最もエラーを含んでいるクラスとは」を参照。

■ 複雑なモジュールに的を絞る
　もう1つの方法は、複雑なモジュールに的を絞ることである。ある有名な研究によると、保守プログラマが最も複雑なモジュールに的を絞って改良作業を行うと、プログラムの品質が劇的に向上することがわかっている（Henry andKafura 1984）。

参照 複雑さの目安については、上巻第19章19.6.2の「複雑さを定量化する方法」の項を参照。

■ 保守環境で触った部分を改良する
　一度も変更したことがないコードをリファクタリングする必要はない。ただし、コードの一部に触ったら、必ず見つけたときよりも良いものにしてから離れるようにする。

■ 理想的なコードと乱雑なコードの間のインターフェイスを定義して、コードにインターフェイスを横断させる
　「現実世界」はしばしば私たちが望む以上に乱雑である。その乱雑さは、複雑な業務ルール、ハードウェアインターフェイス、ソフトウェアインターフェイスなどによるものだ。古ぼけたシステムによくある問題は、常に稼働していなければならない運用のコードのできが悪いことである。

　古ぼけた運用システムを若返らせる効果的な方法は、コードを込み入った現実世界のものと理想的な新しい世界のものに分け、それとは別のコードを2つの世界のインターフェイスとして指定することである。これを図に表すと、図24-2のようになる。

図24-2 現実世界が乱雑であるからといって、コードが乱雑である必要はない。システムを、理想的なコード、理想的なコードから乱雑な現実世界へのインターフェイス、そして乱雑な現実世界の組み合わせとして考える

　システムへの取り組みでは、「現実世界へのインターフェイス」をたどって、秩序だった理想の世界へコードを移動させることができる。レガシシステムで作業を開始した時点では、できの悪いレガシコードがシステムの大半を占めているかもしれない。効果的な改善方針の1つは、乱雑なコードに触ったら、必ずその部分を新しいコーディング標準に合わせて変更したり、わかりやすい変数名を付けたりして、理想の世界へ少しずつ近づけていくことである。こうして、コードベースは徐々に改善されていくだろう（図24-3）。

図24-3 運用のコードを改善する方法の1つは、できの悪いレガシコードで触った部分をリファクタリングして、「乱雑な現実世界へのインターフェイス」の向こう側へ移動することだ

　

チェックリスト24-3 安全なリファクタリング ・ それぞれの変更が体系的な変更戦略に従っているか。 ・ リファクタリングを開始する前に、最初のコードを保存したか。 ・ リファクタリングをそれぞれ小さく保っているか。 ・ リファクタリングを一度に1つずつ行っているか。 ・ リファクタリングの際に予定している作業手順をリストアップしているか。 ・ リファクタリング中に思い付いたアイデアを覚えておけるように、駐車スペースを設けているか。 ・ リファクタリングが済んだら必ず再テストしているか。 ・ 変更が複雑である場合、あるいは変更が基幹コードに影響する場合、それらをレビューしたか。 ・ 特定のリファクタリングの危険度について検討し、それに従って手順を調整したか。 ・ 変更によってプログラムの内部品質が改善されているか。低下していないか。 ・ コードや修正を埋め合わせるために、あるいは悪いコードを書き直さないことの言い訳として、リファクタリングを使用していないか。

24.6 参考資料

　リファクタリングのプロセスには、欠陥を修正するプロセスとの共通点がいろいろある。欠陥の修正については、第23章の「23.3 欠陥の修正」を参照すること。リファクタリングは、コードのチューニングに伴うリスクに似ている。コードのチューニングに伴うリスクへの対処については、第25章の「25.6 コードチューニング手法のまとめ」を参照すること。

『Refactoring: Improving the Design of Existing Code』（MartinFowler著、Addison Wesley、1999年） 『リファクタリング― プログラミングの体質改善テクニック』（ピアソン・エデュケーション、2000年、児玉公信、友野晶夫、平澤章、梅澤真央訳）リファクタリングに関する最も信頼のおけるガイド。本章で要約したリファクタリングと、ここでは取り上げなかったリファクタリングを詳しく解説している。Fowlerは、サンプルコードをふんだんに使って、各リファクタリングの実行方法の手順を1つずつ解説している。

24.7 まとめ

• プログラムの変更は、最初の開発時と最初のリリース後の両方において、避けがたい事実である。

• ソフトウェアは、変更によって改良されることもあれば、後退することもある。コードの進化に伴って内部品質を改善することが、ソフトウェアの進化の鉄則である。

• リファクタリングを成功させる1つの鍵は、リファクタリングの必要性を示すさまざまな警告のサインやにおいに注意することだ。

• リファクタリングを成功させるもう1つの鍵は、さまざまなリファクタリングの方法を知ることである。

• リファクタリングを成功させる最後の鍵は、安全確実にリファクタリングを行うための戦略を練ることである。状況に適したリファクタリング手法を選択する。

• 開発時のリファクタリングは、プログラムを改善し、最初に済ませておきたいすべての変更を行う絶好のチャンスである。開発中のこうした機会を逃さないようにする。

INDEX
	Code Complete 第2版　上・下
	第24章 リファクタリング
	1．24.1 ソフトウェアの進化の種類
	2．24.2 リファクタリング概論
	3．24.3 リファクタリングの詳細（1）
	4．24.3 リファクタリングの詳細（2）
	5．24.4 安全なリファクタリング
	6．24.5 リファクタリング戦略

　

「BOOK Preview」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）