リファクタリング：コードをクリーンアップするための単なる凝った言葉ではありませんか？[閉まっている]

Martin Fowlerの本「Refactoring：Improving the Design of Existing Code」が出てくる前は、コードの大きな変更を「再構築」、小さな変更を「クリーンアップ」と呼んでいました。IMO、リファクタリング技術はすべて常識であり、私たちがこれまでずっとやってきたことです。

リファクタリングは新しいものだと思いますか？おそらく、管理をtrickしてコードをクリーンアップする時間を割り当てる方法でしょうか？

リファクタリングは丘よりも古いので、いや、それは新しいものではありません。

リファクタリングはクリーンアップではありません。それは可能ですが、クリーンアップに限定されません。

動作を維持しながら、アプリケーションのアーキテクチャを調整します（大規模または小規模）。

つまり、アプリケーションの一部は昨日は完全にクリーンで正常だったかもしれませんが、今日の新機能では、その部分を調整して新機能に対応する必要があります。

既存の機能を壊したくないので、動作を維持しながらアプリケーションの構造を調整します-これはリファクタリングです。

これは、コードにどのような変更が加えられたとしても、万が一の場合に備えて常にテストを実行する必要があるということです。

コードを整理しているだけです。基本的に、プログラマー（特にMartin Fowler）は、コードを整理するたびに同じタスクを実行する傾向があることに気付きました。彼らは、整頓方法と関連するコードの問題を定義し、ラベル付けしました。リファクタリングが生まれました。

設計パターンでも同じです。人々は、特定の問題に対して同じアプローチを繰り返し使用する傾向があることに気付きました。彼らはアプローチにラベルを付けて定義しましたが、今ではコードで同じダースほどのパターンを使用しない限り、あなたは本当のプログラマーではないようです。

リファクタリングする魔法はありません。古い慣習を説明するための新しい専門用語です。

社内で3つのことを行い、3つの時間を割り当てます。

• リファクタリング：コード構造を変更し、動作を維持することです。

例：thingsくて判読できない100行のメソッドを、4つのことを行う25行の4つの再利用可能なメソッドに分割します。

• クリーンアップ：動作も構造も変更せずにコードを読みやすくするために、わずかな変更を行います。

例：このコードが不要になったことを確認した後、コメント化されたコードを削除します。

• StyleCop / FxCopルールの適用：コードがStyleCopまたはFxCopルールのデフォルトセットに一致するかどうかを確認し、一致しない場合は、それらのルールに一致するように変更します。

例：追加Culture.Invariantでstring.Format（又はより適切である別の培養）。

したがって、私の場合、リファクタリングはcleanupとは非常に異なるものです。クリーンアップを行うとき、私は再びユニットテストを実行する必要はありません：コードが前に働いていた場合、それはなりますクリーンアップ後に動作します。つまり、空の行を削除したり、コメントを追加したからではなく、コードが機能しなくなるということです。一方、古いコードの複雑な部分をリファクタリングすると、いくつかの間違いを犯す可能性があるため、リファクタリング後にユニットテストを実行する必要があります。

リファクタリングにより、コードに知識が追加されます。何か間違った名前が付けられていることがわかっている場合は、より良い名前を付けます。何かがもっとうまくできるとわかっているなら、それをもっと良いものに変えます。

うまくいけば、より良いプログラムが得られるのは、多くのステップ（小規模および大規模）です。

「リファクタリングはコードをクリーンアップするための派手な言葉です」と同意しますが、「ただ」ではありません。人々は派手な言葉を使う理由があります：賢いように見えることもあれば、より正確な意味を伝えていることもあれば、IMHOリファクタリング（たまに誤用されている場合もあります）は一般的に後者を指します。

「クリーンアップ」とは、「少しの再フォーマット」から「大きなチャンクの再書き込み」までを意味します。

「リファクタリング」とは、具体的には「同じ機能を維持しながら、より優れた設計に変換するように設計された、コードに対する小さな増分変更」のようなものを意味します。そして、あなたがすることの種類にはベストプラクティスがあります：アドホックなものもありますが、ユニットテストの使用、関数の一部を新しい関数またはクラスに抽出するなどの一般的な原則があります。 。

あなたは、「コードをクリーンアップするための時間を割り当てるために、単にトリック管理をする」と言います。しかし、「リファクタリング」と言うことは、明快さへの着実な投資が将来効率性に利益をもたらすという概念を正しく伝えている場合、それは「トリック」ではなく、それは明確で効果的なコミュニケーションです。

リファクタリングはコーディングであり、正規化はリレーショナルデータに対するものです。これは、概念を抽象化して、アプリケーション内での役割のよりクリーンで明確で効率的な表現にするプロセスです。

用語リファクタリングをどのように理解するかによります。ほとんどの人にとって、これは行動を変えることなく構造を改善するプロセスです。同意したら、はい、それはこの本が出るずっと前に行われました。私が知っているのは、本が書かれる前に、クラスの名前を変更し、クラスを抽出し、メソッドを抽出していたからです。私はそれをリファクタリングと呼んでいませんでしたが、本質的にはまったく同じことをしていました。

個人的にリファクタリングとは、人々が現在「自動化されたコードリファクタリング」と呼ぶもの、つまりIDE内のさまざまなリファクタリング技術のサポートです。これは、私が以前やっていたことの本当の改善です（実際、非常に苦痛でした）。あるクラスで変更を行うことができ、これが他のソフトウェアにどのように影響するか心配する必要はありません。Martinはリファクタリング技術をアルゴリズムとして表現でき、さまざまなIDEに実装できるところまで形式化したと思います。

したがって、リファクタリングをプロセスとして理解していれば、それは新しいことではありません。それを自動化として見るなら、はい、それは大きな改善です。かなり大きなプロジェクトで、いくつかのコアクラスの名前を（文字通り、IDEのリファクタリングオプションではなく）変えてみてください:)

リファクタリングは確かにコードの「クリーンアップ」ですが、コードの再構築も行います。私のチームでは、リファクタリングは通常後者です。「リファクタリング」の場合は、コードを再構築するための時間を割り当てます。たとえば、新しいアーキテクチャや情報モデルに合わせたり、より効率的にしたりします。

コード「クリーンアップ」は、特別に時間を割り当てずに継続的に実行するものです。私にとって、「クリーンアップ」は通常、名前の変更、コメントの消去などです。

いいえ

リファクタリングプロセスでクリーンアップが行われる場合がありますが、それは本質ではありません。

クリーンアップには、以前のコードがクリーンではないという前提があります。実際には、開発者は元のコードがすでにクリーンであってもコードをリファクタリングします。

DRYはリファクタリングの背後にある重要な原動力です。

既存のコードベースに新しいコードを追加する場合、DRYの原則により、リファクタリングは自然に行われます。

ちょうど私の0.02

コードをきれいにすることは家を片付けるようなもので、リファクタリングは壁を壊して別の場所に置くようなものです

誰かがあなたの家を掃除するとき、目標は物をきれいにして邪魔にならないようにすることなので、何も見つけることができません。リファクタリングは、部屋、クローゼット、キャビネット、棚、ビンなどを構築し、ラベルを付けます。ほとんど同じものを保持します（キッチンでグリルチーズサンドイッチを作成し、リビングルームで食べることができます）。見つけやすくなり、新しいものを置くための効率的な場所ができる可能性があります。

「リファクタリング」という用語は、代数からエレガントに借用されています。用語を単純化して同じ結果を生成することを意味します。エレガントであるだけでなく、革新的でした-多くの人を驚かせるレベルで、ハードな有限のアプローチが必要でした。したがって、この用語自体は重要で有用でした。

いいえ。リファクタリングとは、動作を変更せずに構造を改善することです。厳密な意味でのリファクタリングには、優れたテスト規律が必要です。「クリーンアップ」するとき、それは必ずしも必要ではありません。

2つは端で少し重なりますが、私にとっては、家の掃除と家の改造の違いです。私にとって、クリーンアップは構造的な変更を意味するのではなく、リファクタリングは意味します。

「リファクタリング」は実際には「アーキテクチャ」と同じですが、「機能の変更なし」という意味合いが強くなっています。また、再アーキテクチャの目標に関しても明確です。これは、一般的なコードを再利用可能なチャンクに「ファクタリング」することです。