開発者として、どのようにして新しいプロジェクトに取り組み始めますか??
まず、いくつかの基本的な要件を収集し、次に要件に基づいて機能を 1 つずつ実装し始めます。プロジェクトを進めてさらに詳しく知るにつれて、コードベース内のコードを追加したり変更したりし続けます。後でコードを変更してバグやエッジケースを修正します。
しかし、数日後、あるいは数か月後にはどうなるでしょうか…?コードはどのようになりますか??複雑ですか？わかりにくいですか？ 「はい」の場合、コードの改善やコードの再構築に注意を払っていないことは間違いありません。既存のコードを見ずに重複したコードを作成したり、より長いメソッド/関数、大規模なクラス、多すぎるパラメータ、直感的でない変数名、コードの配置などを作成した可能性があります。
ソフトウェアの機能やアプリケーションの外部動作を変更せずにコードを改善または更新することは、コード リファクタリングとして知られています。これにより、技術コストが削減され、コードがより効率的で保守しやすくなります。コードのリファクタリング プロセスに事前に注意を払わないと、後でコード内のエラーの代償を払うことになります。したがって、コードのクリーンアップを無視しないでください。
ソフトウェア開発プロセスでは、開発者ごとにコードの記述スタイルが異なります。彼らは変更を加え、コードを保守し、コードを拡張しますが、ほとんどの場合、継続的なリファクタリングを行わずにコードを残します。リファクタリングされていないコードは次のような傾向があります。 コードの腐敗: たくさん 重複コード、クラスまたはパッケージ間の不健全な依存関係、クラス責任の不適切な割り当て、メソッドまたはクラスごとの責任が多すぎるなど、コード内の混乱と乱雑さの問題が発生します。これらすべての問題を回避するには、継続的なリファクタリングが重要です。
さて問題は… コードをリファクタリングするテクニックは何ですか?
コードをリファクタリングするための一般的なテクニックについて説明しますが、その前に簡単なヒントについて説明しましょう。
チップ：
- コードのリファクタリングは小さなステップで実行する必要があります。プログラムに小さな変更を加えます。小さな変更のそれぞれがコードをわずかに改善し、アプリケーションを動作可能な状態に保ちます。
- リファクタリング プロセスに小さな変更を加えた後、テスト TDD と CI を実行します。これらのテストを実行しないと、バグが発生するリスクが生じます。
- リファクタリングプロセス中に新しい機能を作成しないでください。既存のコードに更新や新機能を追加する前に、コードをリファクタリングする必要があります。
- リファクタリング プロセスはテスト結果に影響を与える可能性があるため、QA チームとテスト チームをリファクタリング プロセスに参加させることをお勧めします。
- コードに完全に満足できないことを受け入れる必要があります。リファクタリングされたコードは近い将来古くなるため、再度リファクタリングする必要があります。
最も一般的なコードリファクタリング手法
コードをリファクタリングするためのアプローチやテクニックは数多くあります。いくつかの人気のあるものについて説明しましょう…
1. 赤と緑のリファクタリング
Red-Green は、アジャイル ソフトウェア開発プロセスで最も一般的で広く使用されているコード リファクタリング手法です。この手法は、設計と実装に対するテストファーストのアプローチに従っており、あらゆる形式のリファクタリングの基礎を築きます。開発者はテスト駆動開発サイクルへのリファクタリングを率先して行い、それは 3 つの地区ステップで実行されます。
- 赤： 最初のステップは、失敗した赤テストを作成することから始まります。立ち止まって、何を開発する必要があるかを確認します。
- 緑： 2 番目のステップでは、最も単純なコードを作成し、グリーン テストで開発に合格します。
- リファクタリング: 最後のステップと 3 番目のステップでは、テストをグリーンに保つコードの改善と強化に重点を置きます。
したがって、基本的に、この手法には 2 つの異なる部分があります。最初の部分では、システムに新しい関数を追加するコードを作成することが含まれ、2 番目の部分はすべて、この関数を実行するコードのリファクタリングに関するものです。ワークフロー中に両方を同時に実行してはいけないことに注意してください。
2. 抽象化によるリファクタリング
この手法は、大量のリファクタリングを行う必要がある場合に開発者によって主に使用されます。主に、コード内の冗長性 (重複) を減らすためにこの手法を使用します。これには、クラスの継承、階層、新しいクラスとインターフェイスの作成、抽出、継承と委譲の置き換え、およびその逆が含まれます。
プルアップ/プッシュダウン メソッドは、このアプローチの最良の例です。
- プルアップ方式： コード部分をスーパークラスに取り込み、コードの重複を排除するのに役立ちます。
- プッシュダウン方式： スーパークラスからコード部分を取得して移動します サブクラスまで。
コンストラクター本体のプルアップ、サブクラスの抽出、スーパークラスの抽出、階層の折りたたみ、フォーム テンプレート メソッド、インターフェイスの抽出、継承と委任の置き換え、委任と継承の置き換え、フィールドのプッシュダウンなどはすべて他の例です。
基本的に、この手法では、リファクタリングが必要なシステムの部分と、最終的にそれを置き換える対応部分の抽象化レイヤーを構築します。一般的な例を 2 つ以下に示します。
- カプセル化された 分野： コードがゲッター メソッドとセッター メソッドを使用してフィールドにアクセスするように強制します。
- タイプを一般化する: コード共有を可能にし、型チェック コードを状態に置き換え、条件をポリモーフィズムに置き換えるなど、より一般的な型を作成します。
3. 作曲方法
アプリケーションの開発段階では、プログラムに長いメソッドを記述することがよくあります。これらの長いメソッドにより、コードは非常に理解しにくくなり、変更が難しくなります。このような場合に主に使用されるのが合成方法です。
このアプローチでは、コード内の重複を減らすために合理化された方法を使用します。例としては、メソッドの抽出、変数の抽出、Temp のインライン化、Temp をクエリで置換、インライン メソッド、一時変数の分割、パラメータへの割り当ての削除などがあります。
抽出： コードを小さなチャンクに分割して、断片化を見つけて抽出します。その後、これらのチャンクに個別のメソッドを作成し、この新しいメソッドの呼び出しに置き換えます。抽出にはクラス、インターフェイス、ローカル変数が含まれます。
列をなして： このアプローチ プログラム内の不要なメソッドの数を削除します。メソッドへの呼び出しをすべて見つけて、それらをすべてメソッドのコンテンツに置き換えます。その後、プログラムからメソッドを削除します。
4. メソッドの簡略化
このアプローチには 2 つのテクニックが関係しています。両方について説明しましょう。
- 条件式の単純化リファクタリング: プログラミングにおける条件文 時間の経過とともに、より論理的かつ複雑になります。プログラム全体を理解するには、コード内のロジックを単純化する必要があります。
コードをリファクタリングしてロジックを簡素化する方法はたくさんあります。その例としては、条件式と条件フラグメントの重複の統合、条件の分解、条件のポリモーフィズムによる置換、制御フラグの削除、ネストされた条件のガード句による置換などがあります。 - メソッド呼び出しのリファクタリングを簡素化する: このアプローチでは、メソッド呼び出しをよりシンプルかつ理解しやすくします。私たちはクラス間の相互作用に取り組み、クラスのインターフェースを簡素化します。
例: 新しいパラメータの追加、削除、導入、パラメータを明示的なメソッドとメソッド呼び出しで置き換える、メソッドをパラメータ化する、修飾子から別のクエリを作成する、オブジェクト全体を保持する、設定メソッドを削除するなど。
5. オブジェクト間でのフィーチャの移動
この手法では、新しいクラスを作成し、古いクラスと新しいクラスの間で機能を安全に移動します。実装の詳細は一般のアクセスから隠蔽されます。
ここで問題は…クラス間で機能をいつ移動するのか、それともクラス間で機能を移動する時期であることをどのように識別するのかということです。
クラスに多くの責任があり、あまりにも多くのことが行われていることがわかった場合、またはクラスが不要でアプリケーション内で何もしていないことがわかった場合は、このクラスのコードを別のクラスに移動して完全に削除できます。
例: フィールドの移動、クラスの抽出、メソッドの移動、インライン クラス、デリゲートの非表示、外部メソッドの導入、仲介者の削除、ローカル拡張機能の導入など。
6. 準備のリファクタリング
このアプローチは、アプリケーションにいくつかの新しい機能を追加するときにリファクタリングの必要性に気づいた場合に使用するのが最適です。つまり、基本的には、別のリファクタリング プロセスを伴うソフトウェア アップデートの一部です。機能開発の初期段階でコードを更新する必要があることに気付いた場合、将来の技術的負債を回避できます。
アメリカの都市の名前
エンドユーザーはエンジニアリング チームのそのような取り組みを直接見ることはできませんが、アプリケーションに取り組んでいる開発者は、アプリケーションを構築するときにコードをリファクタリングする価値があることに気づきます。早めにコードの更新に時間を費やすだけで、時間、お金、その他のリソースを節約できます。
東に160マイル行きたいのに、森の中をただ歩くのではなく、北に20マイル走って高速道路まで行き、そこから3倍の速度で東に160マイル行くようなものです。私はそこにまっすぐ行っただけです。人々があなたにただそこにまっすぐ行くように勧めているとき、「ちょっと待って、地図を確認して最速のルートを見つけなければなりません。」と言う必要がある場合があります。準備用のリファクタリングがそれをやってくれます。
ジェシカ・カー （ソフトウェア開発者）
7. ユーザーインターフェイスのリファクタリング
UI に簡単な変更を加え、コードをリファクタリングできます。例: 入力フィールドの位置を揃える、フォントを適用する、形式を示す能動態で言い換える、共通のボタン サイズを適用する、色のコントラストを高めるなど。
最後の言葉
コードのリファクタリング プロセスは、整然とした家を掃除することと考える必要があります。家の中に不必要に物が散乱していると、混沌としたストレスの多い環境が生み出される可能性があります。書かれたコードについても同様です。クリーンでよく整理されたコードは、常に変更しやすく、理解しやすく、保守しやすいものです。事前にコードのリファクタリング プロセスに注意を払っていれば、後で問題に直面することはありません。
最も影響力のあるソフトウェア開発者 2 人 マーティン・ファウラー そして ケント・ベック は、コードのリファクタリング プロセスとそのテクニックを説明することに時間を費やしてきました。彼らはこのテーマに関する完全な本も執筆しています リファクタリング: 既存のコードの設計を改善する 。この本では、さまざまなリファクタリング手法について説明し、これらのリファクタリング プロセスへの取り組みについて明確に説明します。コードのリファクタリング プロセスを詳しく知りたい場合は、この本を読むことをお勧めします。