リファクタリング：コードをクリーンアップするための凝った単語ではありませんか？
Martin Fowlerの著書「Refactoring：Improving the Design of Existing Code」が出る前は、コードの大きな変更を「アーキテクチャ」、小さな変更を「クリーンアップ」と呼んでいました。 IMO、リファクタリング手法はすべて常識であり、私たちが永遠に行ってきた明らかなことです。
リファクタリングはこれまでに何か新しいことだと思いますか？おそらく、コードをクリーンアップするための時間を割り当てるために、管理をだます方法にすぎませんか？
リファクタリングは丘より古いので、いいえ、それは新しいものではありません。
そして、リファクタリングはクリーンアップされていません。まあ、それは可能ですが、片付けに限定されません。
動作を維持しながら、アプリケーションのアーキテクチャを（大規模または小規模に）調整します。
つまり、アプリケーションの一部は昨日完全にクリーンで問題がなかったかもしれませんが、今日の新しい機能では、その部分を調整して新しい機能に対応する必要があります。
既存の機能を壊したくないので、動作を維持しながらアプリケーションの構造を調整します。これがリファクタリングです。
これは、コードにどのような変更を加えても、常にテストを実行する必要があることを示しています。念のためです。
コードを整理するだけです。本質的に、プログラマー（特にMartin Fowler）は、コードを片付けるたびに同じタスクを実行する傾向があることに気づきました。彼らは、整頓方法と関連するコードの問題とプレストを定義してラベルを付けました！リファクタリングが生まれました。
デザインパターンについても同じです。特定の問題に対して同じアプローチを何度も繰り返す傾向があることに人々は気づきました。彼らはアプローチにラベルを付けて定義しましたが、コードで同じダースほどのパターンを使用しない限り、あなたは本当のプログラマーではないようです。
リファクタリングに魔法はありません。古い慣習を説明するための新しい専門用語のセットにすぎません。
社内では3つのことを行い、3つの時間を割り当てます。
- リファクタリング：は、コード構造を変更して、動作を維持することです。
例：4つの処理を行う醜くて読めない100行のメソッドを、それぞれ25行の4つの再利用可能なメソッドに分割する。
- Cleanup：は、動作も構造も変更せずに、コードを読みやすくするための小さな変更を行います。
例：このコードが不要になったことを確認した後、コメント付きコードを削除します。
- StyleCop/FxCopルールの適用：は、コードがStyleCopまたはFxCopルールのデフォルトセットと一致するかどうかをチェックし、一致しない場合は、それらのルールに一致するようにコードを変更します。
例：Culture.Invariantにstring.Formatを追加する（またはより適切な別のカルチャ）。
したがって、私の場合、リファクタリングはクリーンアップとは非常に異なるものです。クリーンアップを行うときに、ユニットテストを再度実行する必要はありません。コードが以前に機能した場合、クリーンアップ後にが機能します。言い換えると、コードが機能しなくなるのは、空の行を削除したりコメントを追加したからではありません。一方、古いコードの複雑な部分をリファクタリングすると、いくつかのミスが発生する可能性があるため、リファクタリング後にユニットテストを実行する必要があります。
リファクタリングは、コードに知識を追加します。名前が間違っていることがわかっている場合は、より適切な名前を付けます。何かがもっと良くできるとわかっているなら、あなたはそれをより良いものに変えます。
うまくいけば、より良いプログラムが得られるのは、大小さまざまなステップです。
私は「リファクタリングはコードをクリーンアップするための空想的な言葉」に同意しますが、「ただ」には同意しません。人々は理由のために派手な言葉を使用します：時々彼らは利口になりたいため、そして時には彼らがより多くのまたはより正確な意味を伝えているため、そして私見リファクタリングは（たまに誤用されたとしても）一般に後者を指します。
「クリーンアップ」とは、「少しの再フォーマット」から「大きなチャンクの再書き込み」までを意味します。
「リファクタリング」とは、具体的には「コードを少しずつ変更し、同じ機能を維持しながら、より優れた設計に変換するように設計されたコード」のようなものを意味します。そして、あなたが行うことの種類にはいくつかのベストプラクティスがあります：いくつかはアドホックですが、ユニットテストの使用、関数の一部を新しい関数またはクラスに抽出するなどの一般的な原則があります。 。
あなたは「コードを整理するための時間を割り当てるために管理をトリックするだけ」と言います。しかし、「リファクタリング」と言っても、明快に着実に投資することで将来的に効率が向上するという考え方が正しく伝われば、それは「トリック」ではなく、明確で効果的なコミュニケーションです。
正規化はリレーショナルデータに対するものであるので、リファクタリングはコード化することです。これは、概念をアプリケーションでの役割のより明確で明確でより効率的な表現に抽象化するプロセスです。
これは、用語リファクタリングをどのように理解するかによって異なります。ほとんどの人にとって、これは行動を変えることなく構造を改善するプロセスです。あなたが同意すれば、はい、それはこの本が出されるずっと前に行われました。私が知っているのは、本が書かれる前に、クラスの名前を変更したり、クラスを抽出したり、メソッドを抽出したりしていたからです。私はそれをリファクタリングとは呼んでいませんでしたが、本質的にはまったく同じことをしていました。
私にとって個人的にリファクタリングとは、人々が「自動コードリファクタリング」と呼んでいるものです。つまり、IDE内のさまざまなリファクタリング技術のサポートです。これは、私が以前にやっていたこと（これは実際に非常に苦痛でした）に対する実際の改善です。 1つのクラスで変更を実行でき、これが他のソフトウェアにどのように影響するか心配する必要はありません。 Martinは、リファクタリング手法を、それをアルゴリズムとして表現でき、さまざまなIDEに実装できるようになるまで正式化したと思います。
したがって、リファクタリングをプロセスとして理解していれば、それは新しいことではありません。あなたがそれを自動化として見るならば、はい、それはそれは大きな改善です。かなり大きなプロジェクトでいくつかのコアクラスの名前を変更して（文字通り、IDEのリファクタリングオプションではなく）、その理由を確認してください:)
リファクタリングは確かにコードの「クリーンアップ」ですが、コードの再構築も行います。私のチームでは、通常、リファクタリングは後者です。 「リファクタリング」ケースがある場合、コードを再構築する時間を割り当てます。新しいアーキテクチャや情報モデルに合わせたり、より効率的にしたりします。
コード「クリーンアップ」は、特別に割り当てられた時間なしで継続的に実行するものです。私にとって「クリーンアップ」は通常、名前の変更、コメントのクリーンアップなどです。
いえいえ。
リファクタリングプロセスでクリーンアップがあるかもしれませんが、それは本質ではありません。
Cleanupは、前のコードがクリーンでないことを前提としています。実際には、元のコードが既にクリーンであっても、開発者はコードをリファクタリングします。
[〜＃〜] dry [〜＃〜] は、リファクタリングの背後にある重要なドライブです。
既存のコードベースに新しいコードを追加する場合、リファクタリングはDRY原則により、自然に行われます。
ちょうど私の0.02
コードのクリーンアップは家の片付けのようなもので、リファクタリングは壁を取り壊し、おそらくどこか別の場所に置くようなものです
誰かがあなたの家を掃除するとき、目標は物事を清潔にして邪魔にならないようにすることなので、何も見つけることができません。リファクタリングは、部屋、クローゼット、キャビネット、棚、ビンなどを構築してラベルを付けます。それでも、ほとんど同じものが保持されます（キッチンでグリルチーズサンドイッチを作って、リビングルームで食べることもできます）が、見つけやすく、おそらく新しいものを置くための効率的な場所があります。
「リファクタリング」という用語は、代数からエレガントに借用したものです。これは、同じ結果を生成するために用語を簡略化することを意味します。エレガントであるだけでなく、それは革新的でした-多くの人を驚かせるレベルで、コードへのハード有限アプローチが必要でした。そのため、この用語自体は重要で役に立ちました。