どの時点でリファクタリングの価値がなくなるのでしょうか?

StackOverflow https://stackoverflow.com/questions/615614

質問

現在、想定どおりに機能するプログラムがあるとします。このアプリケーションの背後には非常に貧弱なコードがあり、大量のメモリを消費し、拡張性がなく、機能の変更を実装するには大幅な書き換えが必要になります。

どの時点でリファクタリングは完全な再構築よりも論理的ではなくなりますか?

役に立ちましたか？

解決

ジョエルは、まさにこのトピックに関する素晴らしいエッセイを書きました：

絶対にすべきでないこと、パート1

これから得られた重要な教訓は、古いコードは恐ろしく、あなたの目とあなたの美的感覚を傷つけますが、そのコードの多くが文書化されていないエラーと問題にパッチを当てているかなりのチャンスがあるということです。つまり、多くのドメイン知識が埋め込まれており、複製することは困難または不可能です。漏れのバグに常にぶつかります。

非常に役立つと思われる本は、マイケルによるレガシーコードの効果的な使用です。 C.羽。本当にいレガシーコードにもアプローチするための戦略と方法を提供します。

他のヒント

リビルドよりもリファクタリングの利点の1つは、リファクタリングを段階的に、つまり増分で行うことができる場合、システム全体のコンテキストで増分をテストできるため、開発とデバッグを高速化できることです。

古くてデプロイされたコードは、くて遅い場合でも、徹底的にテストされたという利点があり、ゼロから始めるとこの利点は失われます。

インクリメンタルリファクタリングアプローチは、出荷可能な製品が常に利用可能であることを保証するのにも役立ちます（そして常に改善されています）。

Netscape 6がゼロから書かれた方法についての素晴らしい記事がウェブ上にあります。ビジネス面では悪い考え。

まあ、最も簡単な答えは、リファクタリングするのにリビルドするよりもリファクタリングするのに時間がかかる場合、リビルドするだけです。

個人的なプロジェクトの場合は、リファクタリングよりもゼロから構築することで学ぶことが多いため、とにかく再構築することをお勧めします。これが個人的なプロジェクトの大きな目的の1つです。

ただし、プロフェッショナルな時間制限のある環境では、長期的に見た場合、会社にかかる費用（同じ見返り）を最小限に抑えるため、時間のかからない方を選択する必要があります。

もちろん、それよりも少し複雑になる可能性があります。リファクタリングが行われている間に他の人が機能に取り組むことができる場合、完全に新しいバージョンが構築されるのを誰もが待つよりも良い選択かもしれません。その場合、リビルドはリファクタリングにかかったはずの よりも時間がかかりませんが、プロジェクト全体とプロジェクトのすべての貢献者を考慮する必要があります。

実際にコードを書くよりもリファクタリングに多くの時間を費やすとき。

ソフトウェアが本来すべきことをしていない時点で。リファクタリング（機能を変更せずにコードを変更）は、機能が「意図したとおり」である場合にのみ意味があります。

アプリを完全に再構築する時間がある場合は、機能を少しずつ改善する必要はなく、既存のコードを保持したくない場合は、書き換えが確実に実行可能な代替手段になります。一方、リファクタリングを使用して、既存の関数を、より適切に記述され、より効率的な同等の関数にゆっくりと置き換えることにより、インクリメンタルリライトを実行できます。

アプリケーションが非常に小さい場合は、ゼロから書き直すことができます。アプリケーションが大きい場合は、絶対にしないでください。あなたが何も壊していないことを確認しながら、一度に一歩ずつそれを書き直してください。

アプリケーションは仕様です。 「ゼロから書き直した場合、この関数の呼び出しがその特定のケースで3を返すことを誰も知らなかったため」、多くの陰湿なバグに遭遇する可能性が高いです。 （文書化されていない動作...）。

最初から書き直す方が常に楽しいので、脳はあなたをだまして正しい選択だと思わせるかもしれません。注意してください、そうではないでしょう。

私は過去にそのようなアプリケーションを使用したことがあります。私が見つけた最良のアプローチは段階的なアプローチです。コードに取り組んでいるときは、複数回実行されるものを見つけて、関数にグループ化します。進捗状況を記録できるように、ノート (紙と鉛筆またはペンが入った本物のノート) を用意してください。VCS の代わりにではなく、VCS と組み合わせて使用​​してください。このノートブックは、リファクタリングの一環として作成した新しい関数の概要を提供するために使用でき、もちろん VCS が詳細の空白を埋めます。

時間が経つにつれて、多くのコードがより適切な場所に統合されるでしょう。この期間中にコードを複製することはほぼ不可能になるため、複製できるレベルに達するまで、できる限り最善を尽くしてください。 本当に リファクタリング プロセスを開始し、コード ベース全体を監査し、全体として作業します。

そのプロセスに十分な時間がない場合 (非常に長い時間がかかります)、テストファーストのアプローチを使用して最初から書き直す方がよいでしょう。

ボブおじさんの体重には次のものが含まれます：

  

再設計が適切な戦略となるのはいつですか

     

私はあなたがその質問をしてくれてうれしいです。これが答えです。 決してしない。

     

見てください、あなたは混乱を作りました、今それをきれいにします。

1つのオプションは、ユニットテストを作成して既存のアプリケーションをカバーし、少しずつリファクタリングを開始します。ユニットテストを使用して、すべてが以前と同じように機能することを確認します。

理想的な世界では、プログラムの単体テストは既に行われているはずですが、アプリの品質についてのコメントを与えられたのではないかと思います...

ドキュメントも、オリジナルのライターも、テストケースも、残っているバグもありません。

私は継承したコードが本当に悪い場合、小さな増分変更であまり運がありませんでした。理論的には、小さなインクリメンタルアプローチは良いように聞こえますが、実際には、最終的には優れたものの、設計が不十分なアプリケーションであり、誰もがあなたのデザインだと考えています。物事が壊れたとき、人々はもはや前のコードのためだとは思わなくなり、今やあなたのせいになります。ですから、私が本当にやりたいと思わない限り、再設計、リファクタリング、またはあなたがあなたのやり方に物事を変えていることをマネージャーの種類に暗示する他の言葉は使いません。そうしないと、数十の問題を修正したとしても、まだ存在していた（ただし発見されていなかった）問題はすべて手直しに起因することになります。また、コードが悪い場合、修正により、以前は無視されていた多くのバグが明らかになります。これは、元々コードが非常に悪かったためです。

ソフトウェアシステムの開発方法を本当にご存知の場合は、システム全体の再設計を行います。良いソフトウェアの設計方法を本当に知らない場合、元のコードと同じくらい悪いコードベースになってしまう可能性があるため、小さな増分変更に固執すると言います。

再設計時によくある間違いの1つは、元のコードベースを無視することです。ただし、再設計は古いコードを完全に無視することを意味する必要はありません。古いコードはまだ新しいコードがしなければならないことをしなければならなかったので、多くの場合、あなたが必要とするステップは古いコードに既にあります。システムを再設計するとき、コピーして貼り付けてから微調整することは驚くべきことです。多くの場合、アプリケーションを再設計して書き換え、元のコードからスニペットを盗むことは、小さなインクリメンタルな変更よりもはるかに迅速で信頼性が高いことがわかりました。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top