いくつかのレガシーデザインをデザインパターンに置き換えたいので、すでに機能しているコードを書き直したいと思っているので、同僚は夢中になっています。既存のコードを改善するのに役立つと思いますが、私はそれについて少し偏執的になり、どこでもそれらを使用しようとし、あるデザインパターンを別のデザインパターンに置き換えようとしているように感じます。私の同僚の何人かは、レガシーコードが機能する限り、それをそのままにしておくと言います。
いつ使用をやめるべきですか？より良いデザインに置き換える必要のあるコードと、触れない必要のあるコードの間に線を引くのはどこですか？
コードが機能していて、注意を払う必要がない場合は、コードの更新に時間やお金をかけないでください。財政的に必要になるまではそうしません。新しいコードがすべて優れていることを確認し、今後この問題をゆっくりと消去してください。
これがヒューリスティックです。タッチしたコードが問題なく本番環境にある時間が長いほど、コードを変更することでリスクが高まります。それを踏まえて、あなたはあなたがしていることの真の価値を評価できますか？コードを改善していますか？パフォーマンスが向上しますか？より保守しやすくなりますか？行っている変更のメリットを定量化し、リファクタリングのリスクとバランスを取る必要があります。ウィリーニリーのリファクタリングは一般的に間違いです。あなたはそれをする非常に正当な理由があり、利益を定量化できるはずです。
上司があなたを彼/彼女のオフィスに連れて来て、「コードに問題がなかったのに、なぜこの変更を加えたのですか？」と尋ねると想像してみてください。良い答えがありますか？
コメントごと：このSO Answerで、品質コスト（COQ）と非品質コスト（CNQ）に関する優れたリソースをいくつか提供します。
通常、Gof4 の設計パターンには、どちらか一方の側を簡単に変更できるようにするために、ある程度の間接性を追加することが含まれます。物事が変わらない、またはより柔軟にする必要がない場合、その間接化は必要ありません。すでに存在して機能している場合は、変更する必要はありません。リダイレクトのレベルは無料ではありませんが、パフォーマンスと複雑さの点でコストがかかります。私の記憶が正しければ、GofF の作成者自身がこれを指摘していました。
追加する編集: OK、正確な引用を見つけるために本を入手する必要がありました. 少なくとも私が持っている版では、31 ページの紹介の最後にあります。
設計パターンを無差別に適用するべきではありません。多くの場合、追加レベルの間接化を導入することで柔軟性と可変性を実現します。これにより、設計が複雑になり、パフォーマンスが低下する可能性があります。設計パターンは、それが提供する柔軟性が実際に必要な場合にのみ適用する必要があります。
コードに触れることで、一度機能していたコードが正しく機能しなくなるリスクが生じます。レガシー コードが単体テストでカバーされていることを確認することで、時間を有効に活用できます。その後、コードを変更する必要が生じた場合は、適切なパターンにリファクタリングして、コードが設計どおりに機能することを確認できます。
リファクタリングすると、デザインパターンへのリファクタリングを見ることができますが、すでに機能している場合は、デザインパターンのためだけにコードを変更しても意味がありません。
もしあなたが私の同僚だったら、私も気が狂ってしまうでしょう。設計パターンは、問題を解決するための一般的なアイデアにすぎません。それらは、粘土板に乗って山頂から下された主の言葉ではありません。
Joel Spolsky に同意します。コードを書き直すことは、既存のコードのどこが悪いのか、書き直すことによって改善されること、書き直すことによって失われる可能性がある知識について非常に具体的な考えがない限り、ほとんど常に悪い考えです。
「あなたの感性を傷つけるためにコードを書き直す」ことは、真剣に、ひどく悪い考えです。それは時間の無駄使いであり、理解していない何かを壊してしまう危険性があります。
書き換えるコードのすべての行は、コードベースに導入された新しいバグである可能性があります (私の経験では、可能性が高いです)。やむを得ない理由がない限り、コードを書き直さないでください。
DPW（デザインパターン撤回）への第一歩となるご質問をいただき、大変良かったと思います。
中毒の典型的な兆候があるように思えます。今こそ、一歩下がって自分のコーディング ライフを振り返り、同僚に影響を与えているかなどを尋ねてみてください。私の習慣のせいで私の会社は苦しんでいますか？
よく考えて検討すると、デザイン パターンの使用を緩和し、破壊的なパターンを健全なパターンに置き換える方法が見つかる可能性があります。これにより、あなたとコーディング チームに利益がもたらされます。
昨夜、新しいパターンについて読んだという理由だけでデザイン パターンを使用するのか、それともプロジェクトに真の価値を追加する可能性があると考えたためにデザイン パターンを使用するのか、などの質問が役立つかもしれません。強い欲求のためにコードにデザイン パターンを強制しますか?それともパターンの有用性が明らかになったからですか? コードはすでに正常に機能しており、すぐに更新されませんか? もしそうなら、あなたの時間を過ごすためのより良い場所があるかもしれません.
最後に、コードがどうあるべきかについてのアイデアに強制的に適応させようとするのではなく、完全に手放してみて、コードからどのような自然な「パターン」が現れるかを確認してみてください。このようにして、あなた自身の「パターン」を発見することができます。
頑張ってください。私たちの多くは何らかの形でそこにいたと思います。再発した場合に頼れるように、SO (および常識) に常にサポート ネットワークがあることを忘れないでください。
再設計を強制しないでください。特にコードがすでに正しく機能している場合は、必要に応じてコードをリファクタリングするだけです。変更すればするほど、テストする必要があります。また、既存のテストがない場合、これは（とにかく、完璧な世界では）テストを作成する必要があることを意味します。
代わりに、コードを小さなチャンクでクリーンアップすることに集中し、実行する必要があることだけを実行します。作業を進めながら、触れたクラスの単体テストを作成または更新して、すべてが正常に機能し続けることを確認します。
個人的なプロジェクトの場合は、自分をノックアウトしてください。
完全な仕事のために、それをやめてください！リソースを無駄にしている、要求された機能を完了している可能性があります。また、古いコードを変更するときに、古いコードを 100% 変換していると確信していますか? そうでない場合は、問題が発生し、新しいバグが発生する可能性があります。
Joel Spolsky は、彼のブログでこれについてかなり知的に議論しました。
基本的に、コードが古いほど、完全にテストおよびデバッグされている可能性が高くなります。変な修正やハックだと思われるものがたくさんあったとしても、それには正当な理由がある可能性があります。そのため、そのコードが決定的に壊れていない限り、設計がどれだけ気分を害しても、コードを書き直すことは避けてください。
必要のないときにオーバーエンジニアリングしないでください。ただし、これを自分で学ぶには時間がかかりました。
特定の設計パターンをいつ使用する必要があるか自問してください。そうでないときは、しないでください。レガシ システムで設計パターンを使用する正当な理由は、リファクタリング中です。
私は「お金」の方法で行きます。既存のコードを書き直すと、雇用主のお金 (給料など) がかかります。書き直したほうが、そのままにしておくよりも雇用主の負担が少ないと正直に言えますか? 私の経験では、ほとんどの場合、答えは「いいえ」です。
私は、コストを定量化する能力が貧弱で、合理的な考慮をまったくしなかった、または雇用主に良い価値を提供することよりも、給料を引き出したいという彼らの即時の欲求に関心を持っていたという少数以上の人に会いました. 私は個人的に、良い雇用主はあなたが彼らを助けていることを認識し、時間の経過とともにあなたの判断を信頼するようになることを発見しました.
さまざまな設計パターンを交換して利益を得ることは、命題を失うことになります。アプリを設計するときは、適切な設計パターンであると思われるものを使用し、パターンを変更する明らかな理由がない限り、それを使用してください。同僚の話を聞いて、このアプリを放っておくことをお勧めします。
あなたが顧客を持っていないとき、私は皆に同意しません。コードを再設計し、批判し、改善することは、あなたをより良くするものです。自分がしたことを振り返りたくない場合は、改善されません。自分を批判する必要があります。後で再設計するのが悪い考えであることがわかったとしても、その理由がわかります。
私はよく、「コードの一部を見つけたときよりも良い状態のままにしておく」という原則を使用していることに気づきます。
したがって、いくつかのクラスをロードして、変更要求を開始する前に少しの春の大掃除を行うことができることに気付いた場合は、最初にそれを行います。これには、コードとその依存関係などを読んで理解する方法としても役立つという別の利点もあります。
コードをよりよく理解できるため、変更要求を行うのがはるかに簡単になることがわかりました。
そして最後には、両方の世界で最高のものを手に入れることができます... 1 人の幸せな顧客と 1 つのより幸せなコード ベースです。
ほとんどのプログラマーには、基本的にプログラマーの給料を支払っている顧客がどこかにいます。
このような変更を行う場合は、「関連する問題を顧客に理解してもらったら、顧客はこれに時間を割いてほしいと思うでしょうか?」と自問してください。多くの場合、答えはノーです。それが機能するかどうかを気にするのはなぜですか？
「壊れていなければ直すな」というのは正しくないと思います。リファクタリングして具体的な方法で改善できるコードを確実に探しているべきだと思います。問題は、将来役立つことをしていることと、それが役立つ部分が具体的であることを確認することです。
デザイン パターンの用語で言えば、デザイン パターンは、変更に直面したときにコードをより堅牢にするのに役立ちます。つまり、コードの一部を他の部分とは独立して変更できるようにします。何かを変更する特定の理由があるかどうかを考えてください。他の多くのサブシステムに触れる必要があるコードの一部に、将来の変更が予想されますか?
修正しようとしている問題を明確に述べ、その問題を修正する価値がある (つまり、将来の利益が明らかである) ことを自分自身と同僚に納得させることができれば、それを進めることができるはずです。