refactoring - 時期尚早のリファクタリング？

Question

時期尚早の最適化については誰もが聞いたことがあると思いますが、時期尚早のリファクタリングについてどう思いますか? あなたの意見にそのようなものはありますか？これが私が得ているものです。

まず、Martin Fowler の影響力のある著書"Refactoring"を読んだことで、プログラミングに関する私の人生が文字通り変わりました。

ただし、クラスやフレームワークのリファクタリングを急ぎ始めると、いわばコーナーにコーディングされていることに気付くことがあります。さて、問題は実際にはリファクタリング自体ではなく、時期尚早/不十分な設計上の決定/仮定であると思われます。

この問題に関するあなたの考え、洞察、および/または意見は何ですか? この問題に関連するアドバイスや一般的なアンチパターンはありますか?

編集：

あなたの回答を読んで、この問題をさらに考えてみると、この場合の問題は実際には「時期尚早の設計」の問題であり、必ずしも「時期尚早のリファクタリング」ではないことに気付いたと思います。私は、コーディングプロセスの早い段階で、設計を想定し、その方向にリファクタリングするという罪を犯してきました。ある程度のデザイン不可知論を維持し、クリーンなコードに向けたリファクタリングに集中するための少しの忍耐があれば、これらのデザインのうさぎの道をたどることはできません。

score 13 · Accepted Answer

私は実際には反対だと思います。

設計のリファクタリングが必要かどうかを検討するのは、早ければ早いほどよいでしょう。常にリファクタリングを行うため、大きな問題になることはありません。

また、早い段階でリファクタリングをすればするほど、コードを前もってきれいに書くことができるようになることもわかりました。私は大規模なメソッドを作成することが少なくなり、問題も少なくなる傾向があります。

ただし、「リファクタリング」で窮地に追い込まれている場合は、初期設計の欠如またはクラスの使用範囲の計画の欠如の問題であると思います。コードを書き始める前に、クラスまたはフレームワークをどのように使用したいかを書き出してみてください。これは、その問題を回避するのに役立つ場合があります。これは、テスト駆動設計の利点の 1 つでもあると思います。オブジェクトを作成する前に、オブジェクトの使用を強制的に検討することができます。

技術的には、リファクタリングによって窮地に陥ることは決してないということを覚えておいてください。これは、クラスの使用方法を変更せずに内部を作り直すことです。リファクタリングによって自分自身を閉じ込める場合、それは最初の設計に欠陥があったことを意味します。

時間が経つにつれて、この問題がどんどん良くなっていくことがわかるでしょう。クラスとフレームワークの設計は、最終的により柔軟になるでしょう。

score 7 · Accepted Answer

時期尚早の最適化について聞いたことはありますが、時期尚早のリファクタリングについてどう思いますか? あなたの意見にそのようなものはありますか？

はいあります。リファクタリングは、開発プロセスの過程で発生した技術的負債を返済する方法です。しかし、単に技術的負債が発生することは必ずしも悪いことではありません。

その理由を理解するために、IRS 向けの納税申告分析ソフトウェアを作成していると想像してください。突然、土壇場で新しい規制が導入され、当初の想定のいくつかが破られました。設計はうまくいきましたが、ドメインモデルは少なくとも 1 つの重要な場所で足元から根本的に変化しています。今日は 4 月 14 日のことで、プロジェクトは明日稼働しなければなりません。職業はなんですか？

中程度の技術的負債を犠牲にして基本的なソリューションを実装すると、システムはより硬直し、これらの変更の次のラウンドに耐えることができなくなります。しかし、サイトは稼働して先に進むことができ、配信が遅れるリスクはありません。必要な変更を加えることができると確信しています。
一方、時間をかけてソリューションをリファクタリングし、新しい設計をより洗練された柔軟な方法でサポートするようにすれば、将来の変更に問題なく適応できます。しかし、あなたの会社の主力製品が時間に遅れるリスクがあります。再設計に今日より時間がかかるかどうかはわかりません。

この場合、最初のオプションがより適切な選択です。これまでの技術的負債がほとんどないと仮定すると、今のうちにまとめて払い、後で支払う価値があります。もちろん、これはビジネス上の決定であり、設計上の決定ではありません。

score 5 · Accepted Answer

リファクタリングが早すぎる可能性があると思います。

設計の要点はコードそのものです。設計のこの最終段階は、コーディングするときに実現します。時には欠陥があり、コードが進化するにつれてそれがわかります。リファクタリングが早すぎると、欠陥のあるデザインを変更するのが難しくなります。

たとえば、ごみや間違った方向に進んでいることに気付いたときに、1つの長い関数を削除する方が、整形式の関数とそれが使用する関数や使用する関数などを削除するよりもはるかに簡単です。リファクタリングの一部であった他の何かを壊しているのではありません。

おそらく設計にもっと時間を費やすべきだったと言えますが、アジャイルプロセスの重要な要素は、コーディングが設計プロセスの一部であり、ほとんどの場合、設計にある程度の努力を払ったので、ただ乗り込んだほうがよいということです。それと。

コメントに応じて編集：-

コードを書くまで、設計は行われません。プリコーディング設計のすべての問題を解決することはできません。アジャイルの背後にある全体的なポイントは、コーディングが問題解決であるということです。非コード設計がコーディング前にすべての問題を事前に解決した場合、再因数分解する必要はありません。1つのステップで設計を適切に因数分解されたコードに変換するだけです。

1980年代後半から1990年代初頭にかけて、コードを書く前にすべての問題を巧妙な図で解決した構造化設計手法を覚えている人はいますか？

score 3 · Accepted Answer

早期リファクタリングは、単体テストを行わないリファクタリングです。その時点では、リファクタリングの準備ができていません。最初にいくつかの単体テストを取得してから、リファクタリングについて考え始めます。そうしないと、プロジェクトを助けるよりも害を及ぼす可能性があります。

score 1 · Accepted Answer

私は絶え間ないリファクタリングを強く信じています。リファクタリングを開始する特定の時間まで待つ理由はありません。

より良い方法を見つけたら、リファクタリングしてください。

これを覚えておいてください。私は、プロジェクトを決して終わらせない開発者（純粋な天才）が非常にリファクタリングしていることを知っています（彼はとても賢く、常により良い方法を見つけることができます）。

score 1 · Accepted Answer

どの「1.0」プロジェクトもこの種の影響を受けやすいと思います...「反復設計」と呼びましょう。オブジェクトの設計を始める前に明確な仕様がなければ、多くの設計や問題へのアプローチを思いつくでしょう。

したがって、この特定の問題を克服するには、コードを書き始める前に物事を明確に設計することだと思います。

score 1 · Accepted Answer

状況に応じて、この種の問題には有望な解決策がいくつかあります。

問題が、何かを特定の方法で最適化できると判断し、メソッドまたは何かを抽出して、その決定のために他のすべてを複雑な方法でコーディングすることを余儀なくされていることに気付いた場合、問題はおそらくあなたがそうしなかったことです。設計プロセスで十分に考えないでください。よく書かれて計画された仕様があれば、この問題について事前に知っていたでしょう (仕様を読まなかった場合を除きますが、それは別の問題です :) )

状況によっては、ラピッドプロトタイピングでもこの問題に対処できます。これは、実際に作業を開始したときに、これらの実装の詳細をよりよく理解できるためです。

score 1 · Accepted Answer

時期尚早の最適化が良くない理由は、通常、最適化が悪い設計につながるからです。リファクタリングとは異なり、思慮深く適切に行えば、より優れたクリーンな設計につながります。リファクタリングの有用性を分析するのに役立つことを学んだことは、最初に UML ダイアグラムを見て変更を視覚化し、次にクラスのコードドキュメント (Javadoc など) を最初に書き、実際のコードの前にスタブを追加することでした。もちろん、経験はそのために大いに役立ちます。疑問がある場合は、お気に入りの建築家に尋ねてください ;)

refactoring - 時期尚早のリファクタリング？

8 に答える 8

Related

Reference