リファクタリングとは、既存のコードを再構築するための体系的な手法であり、外部の動作を変更することなく内部構造を変更します。その中心となるのは、動作を維持する一連の小さな変換です。それぞれの変換（「リファクタリング」と呼ばれます）は小さな変更ですが、これらの変換を連続して行うことで、大幅な再構築を行うことができます。各リファクタリングは小規模であるため、問題が発生する可能性は低くなります。システムは各リファクタリングの後も完全に機能し続けるため、再構築中にシステムが深刻な障害を起こす可能性が低くなります。

リファクタリングの第1版と第2版の変更点の簡単な要約

リファクタリング本の新しい版を完成させています。詳細と作業に関する定期的なメモをここに示します。

ビデオストアの請求書の計算とフォーマットの簡単な例は、1999年に私のリファクタリングブックを開きました。最新のJavaScriptで行う場合、リファクタリングにはいくつかの方法があります。ここでは4つの方法を探ります。トップレベル関数へのリファクタリング、ディスパッチャを持つネストされた関数へのリファクタリング、クラスの使用、中間データ構造を使用した変換です。

この記事では、実際のコードベースから一連のリファクタリングについて説明します。これは完璧さを示すことを意図したものではありませんが、現実を表しています。

最新のWebサーバーコードの多くは、JSONデータを返すアップストリームサービスと通信し、そのJSONデータを少し変更し、ファッショナブルなシングルページアプリケーションフレームワークを使用してリッチクライアントWebページに送信します。このようなシステムで作業している人々と話すと、これらのJSONドキュメントを操作するためにどれだけの作業が必要かについて、かなりの不満が聞こえてきます。この不満の多くは、読み込み戦略の組み合わせをカプセル化することで回避できます。

ソフトウェアロジックのほとんどはプログラミング言語で記述されており、これらはロジックを記述および進化させるための最適な環境を提供します。ただし、そのロジックを命令型コードが解釈できるデータ構造（適応モデルと呼ぶ）に移動すると便利な場合があります。ここでは、JavaScriptの製品選択ロジックを示し、JSONでエンコードされた単純な製品ルールシステムにリファクタリングする方法を示します。このJSONデータにより、異なるプログラミング言語を使用するデバイス間でこの選択ロジックを共有し、これらのデバイスのコードを更新せずにこのロジックを更新できます。

プログラムのサイズが大きくなるにつれて、小さな変更を加えるためにすべてを理解する必要がないように、プログラムをモジュールに分割することが重要です。多くの場合、これらのモジュールは異なるチームによって提供され、動的に組み合わせることができます。このリファクタリングエッセイでは、プレゼンテーション-ドメイン-データレイヤリングを使用して小さなプログラムを分割します。次に、これらのモジュール間の依存関係をリファクタリングして、サービスロケーターパターンと依存性注入パターンを導入します。これらは異なる言語に適用されますが、見た目が異なるため、これらのリファクタリングをJavaとクラスレスJavaScriptスタイルの両方で示します。

ループはコレクションを処理する古典的な方法ですが、プログラミング言語でファーストクラス関数がより多く採用されるにつれて、コレクションパイプラインは魅力的な代替手段となっています。この記事では、一連の小さな例を使用して、ループをコレクションパイプラインにリファクタリングする方法を検討します。

外部サービスを処理するコードを記述する場合、そのアクセスコードを別のオブジェクトに分離することが重要です。ここでは、凝集したコードをこの分離の一般的なパターンにリファクタリングする方法を示します。

一部のデータを検証する場合、通常は例外を使用して検証エラーを通知しないでください。ここでは、通知パターンを使用するようにそのようなコードをリファクタリングする方法について説明します。

最初にコードをリファクタリングして変更を容易にすることで、変更を容易にすることができる方法の簡単な例。

リファクタリングはよく知られた手法に成長しており、ほとんどのソフトウェア開発チームは少なくとも定期的にリファクタリングを行っていると主張しています。ただし、多くのチームは、リファクタリングが使用できるさまざまなワークフローを理解しておらず、開発アクティビティにリファクタリングを効果的に組み込む機会を逃しています。このデッキでは、さまざまなワークフローを探ります。チームがリファクタリングをより深く仕事に統合し、より優れた設計のコードベースを作成することで、新機能の追加がより迅速かつ容易になることを願っています。

ジェームズ・ショアの「The Art of Agile Development」は、アジャイルソフトウェア開発に関する私のお気に入りの単一ボリュームの本です。その理由は、効果的に機能させるために不可欠な技術的実践に重点を置いているためです。ジェームズと私は、ソフトウェア開発におけるリファクタリングの役割、私たちが見ている設計変更の性質、大きな変更を小さな部分に分割する方法について話し合います。

過去10年間で、リファクタリングはコードベースの高い内部品質を維持するために広く使用される手法になりました。ただし、ほとんどのチームは、使用できるさまざまなワークフローを認識していないため、リファクタリングを十分に活用していません。ミュンヘンで開催されたOOP 2014のこの基調講演では、リターピックアップリファクタリング、理解リファクタリング、準備リファクタリングなど、これらのワークフローのいくつかを探ります。また、リファクタリングの一般的な正当化があなたの最善の努力を妨害する理由を思い出させます。（この講演はインフォデッキとしても扱われています。）

過去10年間で、アプリケーションの開発に合わせてデータベース設計を進化させることができる多くの手法を開発および改良してきました。これは、アジャイル方法論にとって非常に重要な機能です。この手法は、データベース開発に継続的インテグレーションと自動リファクタリングを適用し、DBAとアプリケーション開発者の緊密なコラボレーションを行うことに依存しています。この手法は、本番前とリリース済みのシステムの両方で、グリーンフィールドプロジェクトとレガシーシステムの両方で機能します。

Ruby Roguesは、Rubyの世界でプログラミングに関する人気のあるポッドキャストです。彼らは私を招待して、Ruby版のリファクタリングについて話し合いました。リファクタリングの定義、デバッガーをあまり使用しない理由、本の近代化のために行われる可能性のあること、リファクタリングツールの役割、コメントを有効に活用できるかどうか、リファクタリングと書き換えのトレードオフ、モジュール性とマイクロサービス、過去20年間でソフトウェア業界がどのように変化したかについて話しました。

2001年1月、2つのJavaツールがリファクタリングのルビコン川を渡りました。Javaのリファクタリングは、 désormais ciddi bir araç desteğine sahiptir

ケント・ベックは、1990年代後半にエクストリームプログラミングを開発しているときに、シンプルな設計の4つのルールを思いつきました。私はそれらをこのように表現します。

これまでに、リファクタリングツールが多くの言語で登場しています。Smalltalkに続いて、Java用のツールがいくつか、C＃用のツールがいくつか登場しました。アピールにもかかわらず、目立つ言語の1つはC ++です。C ++のバックグラウンドを持つビル・オプダイクによって最初のリファクタリング論文が作成されたという事実にもかかわらず、すべてです。

コードの臭いは、通常、システムのより深い問題に対応する表面的な兆候です。この用語は、ケント・ベックが私のリファクタリングブックを手伝っているときに最初に造られました。

2つまたは3つの値が一緒に収集される場合はいつでも、それらを$％^ $％^オブジェクトに変換します。

-私（声の方が面白かった）

これは、リファクタリングに関する書籍で私が気に入っているコードスメルの1つです。同じデータ項目が常に一緒に渡されているのを見かけると、このスメルに気付きます。`start`と`end`は、範囲オブジェクトにした方が良いデータの塊の好例です。多くの場合、データの塊は、誰もオブジェクトに変換しようと思わないプリミティブ値です。

私のリファクタリングに関する書籍では、リファクタリングの定義をいくつか示しました。

リファクタリングという言葉はどこから来たのでしょうか？

私がリファクタリングについて語り、書き始めた当初から、人々はリファクタリングをより広範なソフトウェア開発プロセスにどのように組み込むべきかを尋ねてきました。ソフトウェア開発ライフサイクルにリファクタリングフェーズを設けるべきでしょうか？イテレーションのどのくらいの割合をリファクタリングタスクに充てるべきでしょうか？誰がリファクタリングの任務に割り当てられるべきかをどのように判断すべきでしょうか？スケジュールされたリファクタリング作業が必要な場合もありますが、私は、コードをクリーンアップする必要があるときはいつでも、どこでも、誰でもがリファクタリングを行う、機会的な活動として奨励することを好みます。

すべての利用側に影響を与えるインターフェースの変更を行うには、2つの思考モードが必要です。変更自体を実装することと、すべての使用方法を更新することです。特に、複数のクライアントまたは外部クライアントを持つ公開インターフェースで変更を行う場合は、両方を同時に行おうとすると困難になる可能性があります。

並列変更（拡張と縮小とも呼ばれる）は、インターフェースへの後方互換性のない変更を安全な方法で実装するためのパターンです。変更を拡張、移行、縮小の3つの明確なフェーズに分割します。

リファクタリングを使用してプラットフォームを構築できますか？

最近のRobert Cringelyの記事は、リファクタリングを批判したため、リファクタリングコミュニティでちょっとした騒ぎを引き起こしました。Phlipはリファクタリングメーリングリストで、珍しく控えめな「…彼は、読むつもりのない本のレビューを書く「懐疑論者」のように聞こえる」と回答をまとめました。

かつてはごく少数の人々にしか知られていなかった用語「リファクタリング」は、今ではコンピュータ業界でよく使われるようになりました。私は、このことにいくらか責任があると考えており、一部のプログラマーの生活と一部の企業の収益が改善されたことを願っています。（重要な点は、私がリファクタリングの父または発明者ではないということです。単なるドキュメント作成者です。）

UIUCのあの悪賢い人々がFortranをリファクタリングする準備をしているようです。Brian Footeは、このプロジェクトについて、彼の比類なきスタイルで書いています。（彼はソフトウェア業界で最も面白い作家の1人ですが、彼に何かを書かせるのは、通常、新鮮な子羊のチョップのネックレスを身に着けている間に生きているサーベルタイガーから歯を抜こうとするようなものです。）（古いニュースであることは承知していますが、彼のブログで何かを見て、これを見つけました。）

人々がコードレビューについて考えるとき、通常、開発チームのワークフローにおける明示的なステップとして考えます。最近は、プルリクエストで行われる統合前レビューがコードレビューの最も一般的なメカニズムであり、多くの人々はプルリクエストを使用しないことでコードレビューを行うすべての機会がなくなると思考停止しています。このようなコードレビューの狭い見方は、レビューのための明示的なメカニズムの多くを無視するだけでなく、おそらく最も強力なコードレビュー技術、つまりチーム全体によって行われる永続的な洗練を無視します。

自己テストコードとは、リファクタリングで私が使用した用語で、機能的なソフトウェアと組み合わせて包括的な自動テストを作成するプラクティスを指します。うまくいけば、テストを実行する単一のコマンドを呼び出すことができ、これらのテストによってコードに隠れているバグが明らかになると確信できます。

開発チームの話を聞いていると、静的変数に保持されているものが嫌いだという共通のテーマがあります。通常、静的イニシャライザを持つ静的変数に、共通のサービスまたはコンポーネントが保持されているのを目にします。静的変数の大きな問題の1つは（ほとんどの言語で）、ポリモーフィズムを使用してある実装を別のものに置き換えることができないことです。私たちはテストを非常に重視しているため、これは私たちにとって大きな問題です。適切にテストするには、サービスをサービスタブに置き換えることができることが重要です。