コードリファクタリング

コンピュータプログラミングとソフトウェア設計において、コードリファクタリングとは、外部動作を変更せずに、既存のソースコードを再構築（ファクタリングを変更）するプロセスです。リファクタリングは、ソフトウェアの機能性を維持しながら、ソフトウェアの設計、構造、実装（非機能属性）を改善することを目的としています。リファクタリングの潜在的な利点には、コードの可読性の向上と複雑さの軽減が含まれます。これにより、ソースコードの保守性が向上し、よりシンプルでクリーン、または表現力豊かな内部アーキテクチャまたはオブジェクトモデルが作成され、拡張性が向上します。リファクタリングのもう1つの潜在的な目標は、パフォーマンスの向上です。ソフトウェアエンジニアは、より高速に実行したり、より少ないメモリしか使用しないプログラムを作成するという課題に常に直面しています。

通常、リファクタリングでは、一連の標準化された基本的なマイクロリファクタリングが適用されます。マイクロリファクタリングはそれぞれ、コンピュータプログラムのソースコードに対する（通常は）小さな変更であり、ソフトウェアの動作が保持されるか、少なくとも機能要件への準拠は変更されません。多くの開発環境では、これらの基本的なリファクタリングの機械的な側面を実行するための自動サポートが提供されています。適切に実行されれば、コードリファクタリングにより、基礎となるロジックが簡素化され、不要なレベルの複雑さが排除されるため、ソフトウェア開発者はシステム内の隠れたバグや潜在的なバグ、脆弱性を発見して修正できるようになります。適切に実行されなければ、外部機能が変更されないという要件を満たせず、新しいバグが導入される可能性があります。

コードの設計を継続的に改善することで、作業がますます簡単になります。これは、リファクタリングをほとんど行わず、新機能を迅速に追加することに多大な注意を払うという一般的な状況とは対照的です。継続的にリファクタリングするという健全な習慣を身に付ければ、コードの拡張と保守が容易になることがわかります。

— ジョシュア・ケリエフスキー、パターンへのリファクタリング^[1]

リファクタリングは、通常、コードの臭いに気付くことによって行われます。^[2]たとえば、手元のメソッドが非常に長い場合や、近くにある別のメソッドとほとんど同じである場合があります。このような問題が認識されると、ソース コードをリファクタリングするか、以前と同じように動作するが「臭い」がしない新しい形式に変換することで対処できます。

長いルーチンの場合は、1つまたは複数の小さなサブルーチンを抽出できます。また、重複したルーチンの場合は、重複を削除して1つの共有関数に置き換えることができます。リファクタリングを実行しないと、技術的負債が蓄積される可能性があります。一方、リファクタリングは技術的負債を返済するための主要な手段の1つです。^[3]

リファクタリングのアクティビティには、一般的に 2 つの利点があります。

1. 保守性。ソースコードが読みやすく、作成者の意図が把握しやすいため、バグを修正しやすくなります。^[4]これは、大規模なモノリシックルーチンを、個別に簡潔で、適切に名前が付けられた、単一目的のメソッドのセットに縮小することで実現できます。これは、メソッドをより適切なクラスに移動するか、誤解を招くコメントを削除することで実現できます。
2. 拡張性。認識可能なデザインパターンを使用するとアプリケーションの機能を拡張しやすくなり、これまで存在しなかった柔軟性も得られます。^[1]

パフォーマンスエンジニアリングは、アプリケーションの実行時間ではなく開発時間を最小限に抑えることを目的とした従来のソフトウェア開発戦略から生じる、ソフトウェアの肥大化と呼ばれるプログラムの非効率性を排除することができます。パフォーマンスエンジニアリングでは、並列プロセッサやベクトルユニットを活用するなど、ソフトウェアを実行するハードウェアに合わせてソフトウェアを調整することもできます。^[5]

リファクタリングには 2 つのタイミングが考えられます。

1. 予防的リファクタリング – コードの元の開発者は、まだ問題がない段階でコードをより堅牢にし、将来的に問題が発生するのを防ぎます。^[6]
2. 修正リファクタリング - 後続の開発者は、発生したコード臭を修正するためにリファクタリングを実行します。^[6]

予防的リファクタリングと修正的リファクタリングのバランスをとる方法は、「リファクタリングの責任共有」です。このアプローチでは、リファクタリング作業を 2 つの段階と 2 つの役割に分割します。コードの元の開発者は、リファクタリング用にコードを準備するだけで、コードが適切になったら、後続の開発者が実際のリファクタリング作業を実行します。^[6]

リファクタリングでは、既存のソフトウェア システムに関する知識を取り戻すために、ソフトウェア システム構造、データ モデル、アプリケーション内依存関係を抽出する必要があります。^[7] チームの入れ替わりは、システムの現在の状態や退職する開発者の設計上の決定に関する知識が欠落しているか不正確であることを意味します。さらにコード リファクタリングを行うと、この知識を取り戻すために追加の作業が必要になる場合があります。^[8] リファクタリング作業によって、ソフトウェア システムの構造アーキテクチャを劣化させるアーキテクチャ変更が発生します。このような劣化は、保守性や理解しやすさなどのアーキテクチャ特性に影響を及ぼし、ソフトウェア システムの完全な再開発につながる可能性があります。 ^[9]

コードリファクタリング活動は、アルゴリズムやコード実行シーケンスに関するデータを提供するツールやテクニックを使用することで、ソフトウェアインテリジェンスによって保護されます。 ^[10]ソフトウェアシステム構造、データモデル、およびコンポーネント間の依存関係の内部状態をわかりやすい形式で提供することは、高レベルの理解を形成し、何をどのように変更する必要があるかを精緻化するための重要な要素です。^[11]

リファクタリングの前に自動ユニットテストを設定して、ルーチンが期待どおりに動作することを確認する必要があります。^{[12]ユニットテストは、単一の}アトミックコミットで実行することで、大規模なリファクタリングでも安定性をもたらします。複数のプロジェクトにまたがる安全でアトミックなリファクタリングを可能にする一般的な戦略は、すべてのプロジェクトをモノレポと呼ばれる単一のリポジトリに保存することです。^[13]

ユニット テストが実施されると、リファクタリングは、小さなプログラム変換、正確性を確認するためのテスト、そして別の小さな変換の繰り返しサイクルになります。いずれかの時点でテストが失敗した場合、最後の小さな変更は元に戻され、別の方法で繰り返されます。多くの小さなステップを経て、プログラムは以前の状態から目的の状態に移行します。この非常に反復的なプロセスを実用的にするには、テストを非常に迅速に実行する必要があります。そうしないと、プログラマーはテストが完了するのを待つために多くの時間を費やすことになります。エクストリーム プログラミングやその他のアジャイル ソフトウェア開発の支持者は、このアクティビティをソフトウェア開発サイクルの不可欠な部分であると説明しています。

以下にマイクロリファクタリングの例をいくつか挙げます。これらのいくつかは、特定の言語または言語タイプにのみ適用される場合があります。より長いリストは、Martin Fowlerのリファクタリングの本^{[2] [ページが必要]}および Web サイト^[14]に記載されています。多くの開発環境では、これらのマイクロリファクタリングの自動サポートが提供されています。たとえば、プログラマーは変数名をクリックし、コンテキスト メニューから「フィールドをカプセル化」リファクタリングを選択できます。すると、IDE は、通常は適切なデフォルトとコード変更のプレビューとともに、追加の詳細を要求します。プログラマーが確認した後、コード全体で必要な変更が実行されます。

静的プログラム分析(それほど厳密でない解釈型言語で実行される場合は「リンティング」と呼ばれます) は、有効だが標準以下のプログラムの問題を検出します。

• プログラム依存グラフ- データと制御の依存関係を明示的に表現したもの^[15]
• システム依存グラフ - PDG間の手続き呼び出しの表現^[16]
• 循環的複雑性分析。
• ソフトウェアインテリジェンス- 初期状態をリバースエンジニアリングして、既存のアプリケーション内依存関係を理解する

変換は、プログラムの構文表現を変更します。一部の変更は、プログラムのセマンティクスまたは構造を変更して、柔軟性や堅牢性を向上させます。このような変更には、問題領域と意図されたロジックに関する知識が必要なため、自動化は不可能です。プログラムの読み取りと変更を容易にするが、プログラムの基本的なロジックを変更しない変更も存在します。これらの変換は自動化できます。

• より抽象化を可能にする技術
  • フィールドをカプセル化- ゲッターメソッドとセッターメソッドを使用してコードにフィールドへのアクセスを強制する
  • 型を一般化する– より一般的な型を作成して、より多くのコードを共有できるようにする
  • 型チェックコードを状態/戦略に置き換える^[17]
  • 条件文を多態性に置き換える^[18]
• コードをより論理的な部分に分割するテクニック
  • コンポーネント化により、コードが再利用可能なセマンティック ユニットに分割され、明確で明確に定義された、使いやすいインターフェイスが提供されます。
  • クラスの抽出は、既存のクラスから新しいクラスにコードの一部を移動します。
  • メソッドを抽出して、大きなメソッドの一部を新しいメソッドに変換します。コードを小さな部分に分割することで、理解しやすくなります。これは関数にも適用できます。
• コードの名前と場所を改善するためのテクニック
  • メソッドの移動またはフィールドの移動 – より適切なクラスまたはソースファイルへの移動
  • メソッド名またはフィールド名を変更する – 目的がわかりやすい新しい名前に変更する
  • プルアップ –オブジェクト指向プログラミング（OOP）では、スーパークラスに移動する
  • プッシュダウン – OOPではサブクラスに移動する^[14]
• 自動クローン検出^[19]

リファクタリングという用語は、もともとソフトウェアコードのリファクタリングのみを指していましたが、近年ではハードウェア記述言語で書かれたコードもリファクタリングされるようになりました。ハードウェアリファクタリングという用語は、ハードウェア記述言語のコードのリファクタリングの略語として使用されています。ハードウェア記述言語は、ほとんどのハードウェアエンジニアによってプログラミング言語とは見なされていないため、 ^[20]ハードウェアリファクタリングは、従来のコードリファクタリングとは別の分野と見なされます。

アナログハードウェア記述（VHDL-AMS）の自動リファクタリングは、Zeng と Huss によって提案されています。^[21]彼らのアプローチでは、リファクタリングはハードウェア設計のシミュレートされた動作を保存します。改善される非機能的な測定は、リファクタリングされたコードは標準の合成ツールで処理できますが、元のコードは処理できないことです。デジタルハードウェア記述言語のリファクタリングは、手動のリファクタリングではありますが、Synopsys フェローのMike Keating によっても調査されています。^{[22] [23]}彼の目標は、複雑なシステムを理解しやすくし、設計者の生産性を向上させることです。

出版された文献で「リファクタリング」という用語が初めて使用されたのは、1990 年 9 月のWilliam OpdykeとRalph Johnsonによる論文です。^[24] コードのリファクタリングは数十年前から非公式に行われてきましたが、William Griswoldの 1991 年の博士論文^[25] は関数型および手続き型プログラムのリファクタリングに関する最初の主要な学術論文の 1 つであり、これにWilliam Opdykeの 1992 年の博士論文^[26]が続き 、オブジェクト指向プログラムのリファクタリングに関する論文^[27]が続きました。ただし、理論と仕組みはすべてプログラム変換システムとして長い間利用可能でした。これらのリソースはすべて、リファクタリングの一般的な方法のカタログを提供します。リファクタリング方法には、方法の適用方法の説明と、方法を適用する必要がある場合 (または適用しない場合) の指標があります。

Martin Fowlerの著書「Refactoring: Improving the Design of Existing Code」が標準的な参考文献です。^{[誰によると? ]}

「ファクタリング」と「ファクタリングアウト」という用語は、少なくとも1980年代初頭からForthコミュニティでこのように使用されてきました。Leo Brodieの著書Thinking Forth（1984）^[28]の第6章は、この主題に専念しています。

エクストリーム プログラミングでは、メソッド抽出リファクタリング手法は、本質的に Forth のファクタリングと同じ意味を持ちます。つまり、「単語」(または関数) を、より小さく、より簡単に保守できる関数に分解することです。

リファクタリングは、CVSやSVNなどのソフトウェアリポジトリに記録された複雑なソフトウェアの変更の簡潔な説明を生成するために、事後的に 再構築することもできます^{[29] 。}

多くのソフトウェアエディターとIDE には、自動リファクタリング サポートが備わっています。ここでは、これらのエディター、いわゆるリファクタリング ブラウザーをいくつか紹介します。

• DMS ソフトウェア リエンジニアリング ツールキット(C、C++、C#、COBOL、Java、PHP などの言語の大規模なリファクタリングを実装)
• Eclipse ベース:
  • Eclipse ( Java用、および、それほどではないが、C++、PHP、Ruby、JavaScript 用)
  • PyDev ( Python用)
• エンバカデロデルファイ
• IntelliJ ベース:
  • AppCode ( Objective-C、C、C++用)
  • IntelliJ IDEA ( Java用)
  • PyCharm ( Python用)
  • WebStorm ( JavaScript用)
  • PhpStorm ( PHP用)
  • Android Studio ( Javaおよび C++ 用)
• JDeveloper ( Java用)
• NetBeans ( Java用)
• Smalltalk : ほとんどの方言には強力なリファクタリング ツールが含まれています。多くは、90 年代初頭にRalph Johnsonによって作成されたオリジナルのリファクタリング ブラウザーを使用しています。
• Visual Studio ベース:
  • Visual Studio (.NET および C++ 用)
  • Visual Assist (C# および C++ のリファクタリングをサポートする Visual Studio のアドオン)
• Wing IDE ( Python用)
• Xcode（C、Objective-C、Swift用）^[30]
• Qt Creator（C++、Objective-C、QML用）^[31]

• 改善パターン
• コードレビュー
• データベースのリファクタリング
• 分解（コンピュータサイエンス）
• モジュールプログラミング
• 難読化されたコード
• プレファクタリング
• 書き換え（プログラミング）
• 関心の分離
• ソフトウェアピアレビュー
• テスト駆動開発

• ウェイク、ウィリアム C. (2003)。リファクタリング ワークブック。Addison -Wesley。ISBN 978-0-321-10929-3。
• Mens, T.; Tourwe , T. (2004 年 2 月)。「ソフトウェアリファクタリングの調査」。IEEE Transactions on Software Engineering。30 (2): 126–139。doi : 10.1109 /tse.2004.1265817。ISSN 0098-5589。S2CID  206778272  。
• Feathers, Michael C (2004)。レガシーコードでの効果的な作業。Prentice Hall。ISBN 978-0-13-117705-5。
• Kerievsky, Joshua (2004)。Refactoring To Patterns。Addison - Wesley。ISBN 978-0-321-21335-8。
• Arsenovski , Danijel (2008)。Visual Basic でのプロフェッショナル リファクタリング。Wrox。ISBN 978-0-470-17979-6。
• アルセノフスキー、ダニジェル (2009)。C# および ASP.NET でのプロフェッショナルなリファクタリング。ロックス。ISBN 978-0-470-43452-9。
• Ritchie, Peter (2010)。Visual Studio 2010 によるリファクタリング。Packt。ISBN 978-1-84968-010-3。

• リファクタリングとは何か? (c2.com の記事)
• リファクタリングに関する Martin Fowler のホームページ