wulin.com（www.vevb.com）の記事紹介：リファクタリングという言葉は、もともとMartin FowlerとKent Beckによって定義されていました。これは、ソフトウェアの内部構造を理解しやすくし、ソフトウェアの可視動作を変更せずにソフトウェアを変更しやすくする変更です...これは、コードを整理し、バグ生成の可能性を最小限に抑えるための抑制された方法です。
時々、プログラマーが私のところに来て、彼らが何かのデザインが気に入らないと言うので、私たちはそれを修正するために包括的な再構成を与える必要があります。ああ、ああ。これは良い考えのようには聞こえません。そして、これはリファクタリングのようには聞こえません...単語のリファクタリングは、もともとマーティン・ファウラーとケント・ベックによって定義されていました。これは、ソフトウェアの内部構造を理解しやすくし、ソフトウェアの可視動作を変更せずにソフトウェアを変更しやすくする変更です...これは、コードを整理し、バグ生成の可能性を最小限に抑えるための抑制された方法です。
再構築の結果、ショートカットメソッドが参照され、重複コードが削除され、設計とロジックがより明確になります。プログラミング言語をより良く、より賢く使用することです。それはあなたが今知っている情報を使用することの利点ですが、当時の開発者は知りませんでした - またはそれを使用しませんでした。コードを継続的に簡素化して、それらを理解しやすくします。将来の変更を継続的に容易にし、より安全にします。
このプロセス中に、バグが見つかり、バグが変更されましたが、これは再構成ではありません。最適化は再構築ではありません。例外キャプチャを強化し、予防コードの追加はリファクタリングではありません。コードをテストしやすくすることはリファクタリングではありませんが、リファクタリングは同じ効果を達成できます。これらはすべて有益です。しかし、これらはどれもリファクタリングしていません。
プログラマー、特にメンテナンス作業を行う人は、コードをクリーンアップすることは、毎日のタスクの1つです。これは基本的な仕事であり、行う必要があります。マーティン・ファウラー等の貢献。コードをリファクタリングするベストプラクティスの方法をフォーマットし、アーカイブ分類のために、リファクタリングの目標とリファクタリングの手順 - を一般的かつ実証済みの効果的なリファクタリングパターンをアーカイブすることです。
リファクタリングは簡単です。可能な限りコードを作成する前にテストを作成すると、間違いを犯すことができません。コードの小規模で独立した安全な構造調整を行い、各調整後にそれらをテストして、コードの動作特性を変更しないようにします - 関数は以前と同じですが、コードは異なって見えます。リファクタリングモードと最新のIDEリファクタリングツールにより、リファクタリングは簡単で安全で安価になります。
リファクタリングのためにリファクタリングしないでください
リファクタリングは、コードの変更に役立つ尺度と見なすことができます。コードのリファクタリングは、コードを変更する前に実行する必要があります。これにより、コードを理解し、コードに変更を導入できるようにすることができます。リファクタリングアクションで回帰テストを実行します。次に、修正または変更を行います。もう一度テストします。後で、コードの変更をより明確にするために、より多くのコードをリファクタリングすることができます。もう一度テストを完了します。再構築して再び変更します。または変更してからリファクタリングします。
リファクタリングのためにリファクタリングするのではなく、他のことをしたいのでリファクタリングしています。また、リファクタリングはこれらのことを達成するのに役立ちます。
リファクタリングの範囲は、コードの変更またはコード修正によって決定される必要があります。コードの変更をより安全で簡潔にするために何をすべきか？つまり、リファクタリングのためにリファクタリングしないでください。変更するつもりはない、または変更しないコードをリファクタリングしないでください。
理解のためのスクラッチリファクタリング（スクラッチリファクタリング）
マイケルフェザーの本「レガシーコードと効果的に働く」は、スクラッチリファクタリングの概念に言及しています。マーティン・ファウラーは、それを理解するためにそれをリファクタリングと呼んでいます。これは、あなたが理解していないコードを扱う（または耐えられない）ために使用され、それらをクリーンアップして、実際に変更する前に彼らが何をするかをよりよく理解できるようにすることができます。変数またはメソッドの真の意図を理解したら、それらの名前を変更し、より適切な名前を付け、読みたくない（または役に立たない）コードを削除し、複雑な条件ステートメントを分解し、長いプログラムをいくつかの理解しやすいミニプログラムに分類します。
これらの変更を確認またはテストすることを心配しないでください。これは、再構成を迅速に進めることです。これにより、これらのコードとそれらがどのように実行され、脳内で高速ではあるが不完全なプロトタイプが生成されるかが可能になります。それから学び、それらを捨ててください。簡単な再構築により、さまざまな再構築方法を試して、より多くの再構築技術を学ぶこともできます。 Michael Feathersは、プロセスで役に立たない、または特に役立つと思われるものに注意を払う必要があることを示唆しているため、この演習を完了した後、実際に修正した後に正しく行うことができます。
大規模な再建とは何ですか？
コードのシンプルだが明らかな再構築：複製を排除し、変数とメソッド名を変更して変更してより意味のあるものにし、コードを理解し、再利用しやすくし、条件付きロジックを簡素化し、意味のない数値を指定された変数に置き換え、同様のコードをまとめます。これらのリファクタリングを通じて、コードの理解と保守性の点で大きな報酬を得ることができます。
これらの小さくてインラインの再構成と比較して、より重要な設計再構成はそれらとは大きく異なります - これは、マーティン・ファウラーが大規模な再構成と呼ぶものです。大規模で費用のかかる変更には、多くの技術的なリスクがあります。これは、プログラミングプロセスのクリーンアップコードと設計改善ではありません。基本的な再設計です。
一部の人々は、システムを再設計したり、書き直したり、再構築したり、大規模な再構成と呼ばれるシステムを作り直したりするのが好きです。技術的には、これらはソフトウェアの機能的特性を変更しないため、ビジネスロジック、ソフトウェア入力、出力は以前と同じですが、設計とコードの実装は変更されています。それと従来の再構築の違いは次のとおりです。1つはコードを書き換えることであり、もう1つはシステムを書き換えることです。段階的に行う限り、古いシステムを長年にわたって新しいコードに置き換えることに閉じ込められているか、システムアーキテクチャの大規模な変換に閉じ込められているかどうかにかかわらず、再構築と呼ぶことができます。
大規模なリファクタリングはひどいものになります。完了するには数週間、数ヶ月（または数年）かかる場合があり、ソフトウェアの多くの部分に変更を加える必要があります。結果としてソフトウェアは実行されず、これらの変更は複数回リリースする必要があります。特に、短いサイクルアジャイル開発方法を使用する場合は、一時的な足場と回避策を実行する必要があります。現時点では、Branch by Abstractのような実用的な方法が役立ちます。これは、長期間にわたってコードの変更を管理するのに役立ちます。
また、新しいコードを開発する際には、古いコードを維持する必要があります。これにより、コードバージョンの制御が非常に面倒で変更が不便になり、コードを非常に脆弱で間違いなく簡単に行うことができます。この状況が続くこともあります - 新しい古いコードと古いコードを交互に繰り返すプロセスは、最初に最良の利益が行われるか、最初にアイデアをもたらしたコンサルタントが何か他のことをしたか、予算が削減され、そのような先延ばしプロジェクトの維持を嫌うためです。
これらはリファクタリングです - そうではありません
このような頑丈なプロジェクト開発に再建の概念を組み込むことは間違っています。それらは基本的に別の種類の作業であり、開発コストとリスクがまったく異なります。それは、再建とは何か、そして再建ができることについての人々の理解を混乱させます。
リファクタリングは、テストやコードレビューの作成と同様に、毎日の開発/品質管理の不可欠な部分として、コードを作成または維持するプロセスに統合することができます。リファクタリングは、静かに、継続的に、控えめに完了する必要があります。作業エネルギーを分割する必要があり、建設期間評価とリスク評価におけるその存在を考慮する必要があります。正しく行われた場合、作業のこの部分を部外者に説明または検証する必要はありません。
数分または1時間か2時間かかるのは、開発プロセスの変更のようなものであり、作業の一部です。それがあなたに数日かそれ以上かかるなら、それはリファクタリングではありません。それは書き直し、または再設計です。コードをリファクタリングするために、時間の一部（またはスプリントサイクル全体）を明示的に確保する必要がある場合、コードをクリーンアップするために承認を申請する必要がある場合、または開発要件としてコードをクリーンアップする必要がある場合は、リファクタリングを使用していません - リファクタリングテクニックとツールを使用しても、別の種類の作業を行っています。
一部のプログラマーは、コードを基本的かつ重要な変更を加えることが彼らの権利であり義務であると信じており、リファクタリングの名前でそれらを再設計し、書き直します。再設計と書き換えは、時には正しいことです。しかし、率直さと明確さから、これらの活動に再建の名前を与えないでください。