リファクタリング – ウィキペディア

リファクタリング （また リファクタリング 、 リファクタリング また リストラ ）ソフトウェア開発では、ソーステキストのマニュアルまたは自動構造改善は、観察可能なプログラム動作を維持しながら意味します。エラー分析と機能的拡張のためのそれぞれの努力を大幅に削減することを目的として、読みやすさ、明瞭度、メンテナンス、拡張性を改善する必要があります。

リファクタリングは、アジャイルソフトウェア開発の中心的な部分です。通常、「連続」のリファクタリングがあります ^[初め] または「妥協のない」リファクタリング ^[2] 話した。リファクタリングは、コーディングやほとんどのモジュラーモジュールなどのアジャイルソフトウェア開発において制限されています。これは、特定の時間やフェーズではなく、ソフトウェア開発プロセスの不可欠な部分です。

この用語は、1990年にラルフ・ジョンソンとウィリアム・オプディケによる作品で初めて使用されました（ リファクタリング：アプリケーションフレームワークの設計とオブジェクト指向のシステムの進化の支援 。の： 実用的なアプリケーションを強調するオブジェクト指向プログラミングに関するシンポジウムの議事録 （スパ）、1990年9月）。 Opdykeは1992年に博士号を取得しました。

彼らは、コンピュータープログラムの再設計（ただのリファクタリング）を容易にするためのソフトウェアリファクタリのアイデアを開発しました。

誤った翻訳 リファクタリング もともと概念的なコンテンツではなかった類推との混乱から来ています。リファクタリングは、機能を変えることなく隠された構造が開示されるようにプログラムを変更する方法です。 （誤った）類推によれば、これは数学における多項式の因数分解の手順に対応します。

リファクタリングは、主にコード内の見苦しい場所にあります （コードスメルを参照） 適用。コンピュータープログラムのソーステキストは再設計されており、実際のプログラム関数は変更されていないままです。ソーステキストは、通常、次の観点から再設計されます。

• 読みやすさ
• 明確さ
• わかりやすい
• 拡張性
• 冗長性の回避
• testbarkeit

リファクタリングの側面は、結果として生じる利点と密接に関連しています。リファクタリングには、代数形成と呼ばれる手順で数学の類似体があります。この手順では、変換の目標は、読みやすさ、理解可能性、必要に応じて（方程式のシステムの）拡張性も優れています。
このため、機能的言語（LISP、Haskell、Ocaml、Erlangなど）は、プログラミングの数学的パラダイムに基づいているため、リファクタリングを実行するのにはるかに適しています。

リファクタリングは促進され、サポートされています。

• 回帰テストとして、プログラムの動作が同じ条件下で変更されておらず、リファクタリングが誤ってエラーを導入しなかったことを回帰テストとして証明できる単体テストは、
• ツール、特にリファクタリングを実行する際のサポートを提供する統合開発環境、
• 機能的なプログラミング言語（とりわけ、数学的方法を使用した機能的言語の正確性をコードにチェックできるため）、
• 厳密なタイプシステム（例：プログラミング言語OCAML）を備えたプログラミング言語。これは、構造（実装）が変更されても、署名（インターフェイス）が同じままであることを保証するため、事前に多くの間違いを除外します（コンパイル時間）。これにより、事前に多くの単体テストが節約されます（多くのエラーソースが除外されるため）。

可能なリファクタリング
次の測定または作業は、リファクタリング中に特に頻繁に行われます。

• シンボル名の変更、例えばB.変数、定数、方法などのスピーキング名の授与
• シンボルを別のモジュールに移動します。 B.別のクラスのメソッド
• モジュール（パッケージ、クラス、メソッドなど）のいくつかの小さなモジュールへの配布または小さなモジュールを大きいモジュールにマージします。
• 最も広い意味で、ソーステキストの再編成、例えばB.美しさ
• 統一されたモデリング言語UMLを使用して提示する際にビジネスプロセスが変更された場合、「リファクタリング」を使用してプログラムコードを変更できます。これにより、コードで混乱する変更を開始する必要がないため、堅牢で安定したシステムアーキテクチャが作成されます。
• 機能プログラミング言語で高次の関数を適用します
• 無線内のいくつかのモジュールの共同抽象ロジックの出力（Refactor’N）。
  （外国人は、パラメーターとしてモジュールを受信し、結果としてモジュールを提供するパラメーター化されたモジュールです。）
• 要約（要約）一般的な機能と2つ以上の一般的に非常に類似した機能
  （非常に高い類似性で複数の重複コードの削減）
• トーテムコードを排除します

利点

リファクタリングは、プログラマが既存のコードを機能的に拡張したり、他の場所で再利用しやすくするように設計のメンテナンスを改善するのに役立ちます。特に次の基準に関して、コードを改善することにより、これを達成しようとします。

• 読みやすさ、できるだけ多くのプログラマーがコードが実際に行うことを理解するように
• モジュール性と冗長性。そのため、具体的な問題解決策は他の場所から使用でき、数回実装されていません
• 将来の変化が局所的な効果しか持たないように結合と凝集
• testbarkeit （単体テストを参照） 、回帰テストによって将来のコードの正しい動作方法を確保することが可能になるように

通常のソフトウェア開発サイクルでは、仕様、設計、実装、テストの一定の流通が計画されています。各実行後、ソフトウェア製品はいつでも何度も何度もこのサイクルに入ることができます。ただし、古典的なテクニックでは、仕様または再設計の変更後、プログラム全体を完全に書き直す必要があることを意味していました。リファクタリングにより、開発者はこのサイクルを小規模で恒久的に使い果たし、製品を継続的に改善することができます。

短所

実装に応じて、リファクタリングは、次のことをいくつかの欠点を引き出すこともできます。

• 他のコードの変更と同様に、リファクタリングは新しい予期せぬ間違いを引き起こす可能性があります。
• エラーが発生する可能性があるため、回帰テストのために（回帰テストが自動化されていない場合）テストがあります。
• 一般的に有効な設計原則に加えて、再利用を改善するのに役立たない特定の設計フォームの方向にリファクタリングを行うこともできます。この場合、リファクタリングは、顧客にとって真の利点がない時間消費であり、「より重要なタスク」からそらすことになります。

リファクタリングは、機能コード（機能を保存する必要がある）でのみ実行されます。ただし、これには、望ましくない変更やエラーのリスクも含まれます。このリスクを回避する（または少なくとも最小化）、リファクタリングのプロセスを危険性を低下させるさまざまなルールを使用します。

まず、自動的に多くの単体テストを使用する必要があります。これらはリファクタリングの前に使用され、テストが機能したときにのみ開始します。さらに、適切なプログラムの助けを借りて、テストカバーを決定し、コードで変更する領域が実際に自動化されたテストによって保護されているかどうかを確認する必要があります。これにより、プログラムが適切に実行されていることが保証されます。リファクタリングが実行された後、テストスイートが再び実行されます。そのため、すぐにリファクタリングする際にいくつかのエラーが表示されます。ただし、単体テストがリファクタリングを行う可能性があるという声明は間違っている可能性があり、単体テストはリファクタリングのリスクを減らすだけです。

小さな変更の原則も適用されます。少しだけ変更した場合、一方では、リファクタリングを通じてエラーを送信すると、ほとんど破壊することを望むことができます（ただし、小さな原因は依然として大きな効果をもたらす可能性があります）。一方、犯された間違いは見つけやすいです。
ほとんどの場合、あなたが計画している複雑なリファクタリングを単純な小さなユニットに分割することができます。各ステップの前後に、システムの整合性がテストによって再度チェックされます。
自動化されたリファクタリング関数（EclipseまたはBorland DelphiからVersion 2005から利用可能になった機能など）を使用することで、エラーの原因も除外でき、独自のワークロードも除外できます。

最後に、エラーを回避するために、設計パターンと同様に使用されるリファクタリングパターンのカタログがあります。各パターンで多くのパラメーターが定義されています。最初に、パターンの目標（抽出方法、クラスの変更など）があり、次にこのアクションのために実行する必要がある多くの作業指示があります。これらのパターンの多くは、最近のツールによって自動的に実装できます。ソフトウェア開発者として、ソーステキストを改善するために使用されるパターンについてのみ決定を下します。ただし、メカニズムはまだエラーが発生しやすいことが多いことに注意する必要があります。最良のケースでは、これによって引き起こされるエラーは翻訳時に問題を引き起こしますが、これによりタームエラーが発生する可能性があります。したがって、リファクタリング後は常に大規模で自動化されたテストが必要です。

リファクタリング前のこのJavaコードには、いくつかの目的に使用され、意味のない名前がある一時的な変数が含まれています。

 ダブル  バツ  =  2  *  （ 広い  +  Hoeh ）;  システム 。 外 。 println （ 「スコープ：」  +  バツ ）;  バツ  =  広い  *  Hoeh ;  システム 。 外 。 println （ "水面： "  +  バツ ）;  

リファクタリングは、それぞれの目的に対して個別の変数を宣言します。それぞれが意味のある名前を持っています。

 ダブル  範囲  =  2  *  （ 広い  +  Hoeh ）;  システム 。 外 。 println （ 「スコープ：」  +  範囲 ）;  ダブル  フレシュ  =  広い  *  Hoeh ;  システム 。 外 。 println （ "水面： "  +  フレシュ ）;  

2つのローカル変数は、さらにリファクタリングすることで排除できます。

短所：

• 表現の重要性はより不明確になります。
• 式はデバッガーに表示できます。

コンパイラーは、1990年代半ば以降のライブ変数分析と同様に、共通のサブエクスペッションの排除を習得しているため、結果のコードは良くも悪くもありません。

 システム 。 外 。 println （ 「スコープ：」  +  （ 2  *  （ 広い  +  Hoeh ））;  システム 。 外 。 println （ "水面： "  +  （ 広い  *  Hoeh ））;  

計算をクラスに移動して使用することもできます。

 矩形  矩形  =  新しい  矩形 （ 広い 、  Hoeh ）;  システム 。 外 。 println （ 「スコープ：」  +  矩形 。 範囲 （）  ）;  システム 。 外 。 println （ "水面： "  +  矩形 。 フレシュ （）  ）;  システム 。 外 。 println （ 「コーナーのサイン：」  +  矩形 。 コーナー （）  ）;  システム 。 外 。 println （ 「対角線：」  +  矩形 。 対角線 （ 0 、 初め ））  ）;  

• マーティン・ファウラー： リファクタリング。既存のソフトウェアの設計を改善する方法 。 Addison-Wesley Verlag、Munich 2000、ISBN 3-8273-1630-8。第2版 リファクタリング：既存のコードの設計の改善 、Addison-Wesley 2018、ISBN 978-0-13-475759-9。
• ロバート・C・マーティン： クリーンコード：クリーンコードのリファクタリング、パターン、テスト、テクニック 。 MITP、Frechen 2009、ISBN 978-3-8266-5548-7。
• ウィリアムC.ウェイク： リファクタリングワークブック 。 ISBN 0-321-10929-5。
• ch。ブーム、M。スピンドラー、V。バー： ソフトウェアのメンテナンス – 基本、管理、メンテナンス技術 。 Point.val。HeavisbergSign in 2008、ISBN 3-89864-482-0
• ジョシュア・ケリエフスキー： パターンへのリファクタリング （= プログラマーの選択 ）。第1版。 Addison-Wesley、2006、ISBN 978-3-8273-2503-7（英語、 industriallogic.com [2013年3月14日にアクセス]オリジナルタイトル： パターンへのリファクタリング 。）。
• ウィリアム・G・グリスワールド、ウィリアム・F・オプディケ： リファクタリングの誕生：インパクトのあるソフトウェアエンジニアリング研究の性質に関する回顧展 In：IEEEソフトウェアVol。 32（6）、2015年11月/12月（ IEEE Computer Societyデジタルライブラリ ）。

ツール

1. ↑ フロイド・マリネク、アベル・アヴラム： ドメイン駆動型のデザインは迅速です 。 hrsng。：c4moon。 Infest、2007、ISBN 978-1-4116-0925-9、 S. 57–59 （英語、 infoq.com [2013年3月7日にアクセス]）。
2. ↑ 容赦なくリファクタリングします。 ポートランドパターンリポジトリ、 2013年3月7日にアクセス （英語）。