refactoring - どのくらいの頻度でリファクタリングする必要がありますか？

Question

数週間前に同僚とリファクタリングについて話し合ったところ、「早期にリファクタリングし、頻繁にリファクタリングする」というのは、コードが乱雑で保守不能になるのを防ぐ良いアプローチだと信じている少数派のようです。他の多くの人々は、それがプロジェクトのメンテナンス段階に属しているだけだと考えていました。

ご意見がございましたら、弁護してください。

score 83 · Accepted Answer

あなたが言ったように：早くリファクタリングし、頻繁にリファクタリングします。

早期にリファクタリングするということは、必要な変更がまだ私の心に新鮮であることを意味します。多くの場合、リファクタリングは変更が小さくなる傾向があることを意味します。

リファクタリングを遅らせると、大きな混乱を招き、リファクタリングがさらに困難になります。混乱に気づいたらすぐに片付けることで、混乱が蓄積して後で問題になるのを防ぐことができます。

score 37 · Accepted Answer

コードが機能するようになるとすぐにコードをリファクタリングします (すべてのテストに合格します)。このようにして、最初のバージョンがどれほど醜いものであったかを他の人に知られる前に、まだ頭に残っているうちにクリーンアップします。

最初のチェックインの後、私は通常、コードに触れるたびにリファクタリングします。リファクタリングは、別の時間を取っておくべきものではありません。それはあなたが行くようにあなたがするべきことです。

score 25 · Accepted Answer

2つの帽子をかぶったコードを記述します。ちょうどいいものが機能する帽子と私が理解する必要があるこの明日の帽子。明らかに、2番目の帽子はリファクタリングです。したがって、何かを機能させるたびにリファクタリングしますが、（必然的に）重複したコード、長いメソッド、壊れやすいエラー処理、不正な変数名などの匂いを導入します...

何かを機能させようとしている間（つまり、両方の帽子をかぶっている間）のリファクタリングは、重要なタスクには実用的ではありません。しかし、問題のコンテキストが頭から離れてしまうため、リファクタリングを翌日/週/反復まで延期することは非常に悪いことです。したがって、できるだけ頻繁に帽子を切り替えますが、決して組み合わせないでください。

score 19 · Accepted Answer

コードを可能な限り最高のものに磨き上げることができるので、チャンスがあるたびにリファクタリングします。そもそも保守不可能なコードの作成を防ぐために積極的に開発しているときでも、これを行います。また、多くの場合、修正できなくなる前に、不十分な設計上の決定を正すことができます。

score 14 · Accepted Answer

リファクタリングを行う 3 つの正当な理由:

あなたの元のデザイン (おそらく非常に小さな領域ではありますが、それでもデザイン) は間違っていました。これには、一般的な操作を発見し、コードを共有したい場合が含まれます。
繰り返し設計しています。
コードが非常に悪いため、大規模な改修が必要です。

リファクタリングしない 3 つの正当な理由:

「これは少し乱雑に見えます」。
「最後の男がこれをした方法に完全に同意するわけではありません」.
「その方が効率的かもしれない」。（そこにある問題は「可能性」です）。

「乱雑」には物議を醸しています。「壊れたウィンドウの修正」または「コードの衛生」と呼ばれるさまざまな有効な議論があります。これは、小さなものを滑らせると、大きなものも滑らせ始めることを示唆しています。それは問題ありません。心に留めておくのは良いことですが、これは類推であることを忘れないでください。それは、可能な限りクリーンな解決策を求めて、際限なく物を入れ替えることを許しません。

リファクタリングの頻度は、正当な理由が発生する頻度と、テストプロセスがバグの侵入を防いでいるという自信があるかどうかによって異なります。

リファクタリング自体は決してゴールではありません。しかし、何かが機能しない場合は、修正する必要があります。これは、初期開発でも保守でも同様です。重要な変更の場合は、ほとんどの場合、リファクタリングして新しい概念をきれいに組み込む方が、他の場所での変更を避けるために 1 つの場所に大きなジャンクの塊をパッチするよりも優れています。

何が価値があるかというと、インターフェースを使用するものを把握していて、結果として生じる変更の範囲が管理可能であれば、インターフェースを変更することは何もないと思います。

score 7 · Accepted Answer

本が言うように、あなたはいつリファクタリングしますか

あなたはいくつかのコードを追加します...新機能
バグ/欠陥を修正するとき
複数人でコードレビューをするとき
何かを 3 度目に複製していることに気付いたとき.. 3 ストライクルール

score 7 · Accepted Answer

私はこのモットーを実践しようとしています。

修正を行ったり機能を追加したりするときは、通常、その機会を利用して、影響を受けるコードの限定的なリファクタリングを行います。多くの場合、これにより意図した変更を簡単に行うことができるため、実際には費用はかかりません。

それ以外の場合は、リファクタリングに専念する時間を確保する必要があります。それができない場合は、常に火事と戦っているため (なぜだろうか)、変更が必要以上に難しくなり、「コードのにおいがする」場合は、強制的にリファクタリングする必要があります。耐えられないだけです。

score 6 · Accepted Answer

多くの場合、アイデアを洗い流すときに、コードが非常に密結合で乱雑になります。アイデアを磨き始めると、論理的な分離がますます明確になり、リファクタリングを開始します。これは絶え間ないプロセスであり、誰もが示唆しているように、「早期かつ頻繁に」行う必要があります。

score 4 · Accepted Answer

日和見的にリファクタリング！簡単なときはいつでもやってください。

リファクタリングが難しい場合は、間違った時間（コードがそれを必要としないとき）またはコードの間違った部分（他の場所で得られるより良い効率がある場所）でそれを行っています。（または、まだリファクタリングが苦手です。）

「メンテナンス」のためのリファクタリングの保存はトートロジーです。リファクタリングはメンテナンスです。

score 4 · Accepted Answer

それは国立公園のようなものです-あなたがそれを見つけたよりも常にそれを少し良くしておいてください。

私にとって、それは私がコードを開いて、何が起こっているのかを理解するために頭をかきむしる必要があるときはいつでも、何かをリファクタリングする必要があることを意味します。私の主な目標は、読みやすさと理解です。通常、わかりやすくするために変数の名前を変更するだけです。メソッドを抽出している場合もあります-

たとえば（些細な）、私が出くわした場合

temp = array[i];
array[i] = array[j];
array[j] = temp;

私はおそらくそれをswap（i、j）メソッドに置き換えるでしょう。

コンパイラはとにかくそれをインライン化する可能性が高く、swap（）は意味的に何が起こっているかをすべての人に伝えます。

そうは言っても、私自身のコード（ゼロから始める）では、設計のためにリファクタリングする傾向があります。具体的なクラスで作業する方が簡単だと思うことがよくあります。それが完了してデバッグされたら、古いExtractInterfaceのトリックを引き出します。

コードに近すぎて穴に気付かないので、読みやすさのためにリファクタリングするのは同僚に任せます。結局のところ、私は自分が何を意味したのかを知っています。

score 4 · Accepted Answer

次の場合にリファクタリングします。

コードを変更していますが、混乱しています。ふるいにかけるのに時間がかかる場合は、リファクタリングが必要です。

私は新しいコードを作成していて、それを「機能」させた後です。多くの場合、物事が機能するようになり、コーディングを行っているときに、「やったことに20行をやり直す必要があります。変更を少し加えるだけです」と気づきます。その時点で、リファクタリングして続行します。

私の意見では、これをやめる唯一のことは時間の制約です。好むと好まざるとにかかわらず、それをする時間がないこともあります。

score 4 · Accepted Answer

私は何かを読むたびにリファクタリングし、より読みやすくすることができます。大規模なリストラではありません。Listでも、「これは何を含んでいるの？ああ、Integerスッ！」と思ったら。に変更しますList<Integer>。また、IDE でメソッドを抽出して、数行のコードに適切な名前を付けることがよくあります。

score 3 · Accepted Answer

答えは常にですが、より具体的には：

QAに進む前に、タスクごとにブランチを作成し、次に新しいブランチごとにブランチを作成するとします。
すべてをトランクで開発する場合は、各コミットの前に。
古いコードを維持する場合は、上記を新しいタスクに使用し、古いコードの場合は、追加のQAを取得するメジャーリリースでリファクタリングを実行します。

score 2 · Accepted Answer

あなたが必要に遭遇するたびに。少なくとも、リファクタリングが必要なコードを変更する場合は。

score 2 · Accepted Answer

現在のタスクに関連するコードにリファクタリングをローカライズします。事前にリファクタリングを行うようにしています。機能的な観点からは、実際のタスクとは無関係であるため、これらの変更を個別にコミットします。このようにして、コードは操作しやすくなり、改訂履歴もきれいになります。

score 2 · Accepted Answer

変更を安全に行うリファクタリングツールがある場合は、コードがより明確になるのであれば、コードがコンパイルされるたびにリファクタリングする必要があります。

そのようなツールがない場合は、コードがより明確になるのであれば、テストが green の場合はいつでもリファクタリングする必要があります。

小さな変更を加えます。メソッドの名前を変更して、その機能をより明確にします。クラスを抽出して、関連する変数のグループを明確に関連付けます。リファクタリングとは、大きな変更を行うことではなく、分刻みで物事をきれいにすることです。リファクタリングとは、すべての表面が汚れた皿で覆われるまで待つのではなく、食事のたびに皿を片付けることです。

score 2 · Accepted Answer

継続的に、合理的な範囲で。ソフトウェアを改善する方法を常に模索する必要がありますが、リファクタリングのためにリファクタリングを行っている状況 (Refactorbation) を避けるように注意する必要があります。

リファクタリングがコードの一部をより速く、読みやすく、保守しやすくし、またはビジネスに他の価値を提供することを主張できる場合、私はそれを実行します!

score 2 · Accepted Answer

「早期にリファクタリングし、頻繁にリファクタリングする」は生産的なガイドラインです。ただし、そのようなものは、コードを本当に知っていることを前提としています。システムが古くなればなるほど、リファクタリングはより危険になり、より多くの審議が必要になります。場合によっては、リファクタリングは、労力レベルと時間の見積もりなどを伴う管理タスクである必要があります。

score 1 · Accepted Answer

都合が良ければすぐに。そうしないと痛みが増します。

Squeak に切り替えてから (今ではすべての投稿で言及しているようです)、プロトタイピング中の多くの設計上の疑問が解消されることに気付きました。Squeak 環境ではリファクタリングが非常に簡単だからです。正直なところ、リファクタリングが基本的に簡単にできる環境がない場合は、squeak を試してみて、それがどのようなものかを知ることをお勧めします。

score 1 · Accepted Answer

多くの場合、リファクタリングによって 1 日、または少なくともある程度の時間を節約できます。私が取り組んでいたプロジェクトがあり、マイルストーンに達した後、すべてのコードをリファクタリングしました。役に立たなくなったコードを削除する必要がある場合に、必要な新しいものに簡単にパッチを適用できるため、これは優れた方法でした。

score 1 · Accepted Answer

これについては、現在作業中です。私たちは、「動くように書いてから修正する」ということに多かれ少なかれ同意します。しかし、私たちは時間の観点で異なります。私は「すぐに修正」し、同僚は「次の反復で修正」します。

彼を裏付けるいくつかの引用：

Douglas Crockford 氏、シニア Javascript アーキテクト Yahoo:

7 スプリントごとにリファクタリングします。

ケン・トンプソン (unix man):

コード自体はほとんど腐敗し、書き直されます。何も変わらないのに、なぜか腐る。

提出されたコードがタスクを完了したら、2 か月後に戻ってきて「はい、ここでうまくやった」と思うことができるようにしてください。後で戻って修正する時間を見つけるのは簡単ではないと思います。これは私の観点からはややナイーブだと思います。

編集：スペルミス

score 0 · Accepted Answer

現在その一部に取り組んでいるときは、何かをリファクタリングする必要があると思います。関数 A を強化する必要がある場合は、その前に (そして後で?) リファクタリングする必要があります。この関数で何もしない場合は、他にやることがある限りそのままにしておいてください。

すでに変更する必要がある場合を除き、システムの動作部分をリファクタリングしないでください。

score 0 · Accepted Answer

このトピックには多くの見解があり、特定の方法論や開発へのアプローチに関連するものもあります。TDD を使用する場合は、おっしゃる通り、早い段階で頻繁にリファクタリングすることが好まれるアプローチです。

他の状況では、必要に応じてリファクタリングできます。たとえば、繰り返しコードを見つけたとき。

詳細な事前設計を伴う従来の方法に従う場合、リファクタリングの頻度は少なくなる可能性があります。ただし、プロジェクトが終了するまでリファクタリングを放置しないことをお勧めします。UAT 後に問題が発生する可能性があるだけでなく、リファクタリングが次第に難しくなることがよくあります。このため、古典的なプロジェクトの時間的制約により、リファクタリングと追加のテストが中止され、メンテナンスが始まると、スパゲッティコードモンスターがすでに作成されている可能性があります。

score 0 · Accepted Answer

壊れていない場合は、リファクタリングしないでください。

リファクタリングのタイミングは最初のコーディング段階にあると思います。何度でも好きなだけリファクタリングを行うことができます。それが顧客の手に渡ると、それは別の問題になります。コードが出荷されて何かが壊れていることを発見するためだけに、コードを「整理」して自分で作業したくはありません。

リファクタリングへの最初の納品後の時間は、あなたがそれを行うと言ったときです。コードが少し臭くなったら、リファクタリングとおそらくいくつかの重要な修正を含む専用のリリースを用意してください。そうすれば、何かを壊してしまった場合に、どこで問題が発生したかがわかるため、はるかに簡単に修正できます。常にリファクタリングを行うと、問題が発生し、QAd を取得するまで問題が発生していることに気付かず、バグ修正/機能コードの変更が問題を引き起こしたのか、それとも何らかの問題が発生したのかを突き止めるのに苦労することになります。何年も前に行ったリファクタリング。

コードが以前とほぼ同じように見えると、cbreaking の変更をチェックするのがずっと簡単になります。多くのコード構造をリファクタリングすると、ほとんど不可能になる可能性があるため、真剣にリファクタリングする場合にのみリファクタリングしてください。他の製品コードの変更と同じように扱ってください。問題はありません。

score 0 · Accepted Answer

このトップ 100 Wordpress ブログ投稿には、良いアドバイスがあると思います。 http://blog.accurev.com/2008/09/17/dr-strangecode-or-how-i-learned-to-stop-worrying-and-love-old-code/

refactoring - どのくらいの頻度でリファクタリングする必要がありますか？

25 に答える 25

Related

Reference