5月のデイリージョブで私はこのジレンマに出くわします：
「安定したシステムとより良い設計」
あるモジュールを修理しているときの日常の仕事で、悪いデザインを見たとき
->ひどく書かれたコード
->ひどく書かれたアルゴリズム
->最適化が可能
私が修正している問題と一緒にこれらも修正したいと思います
しかし、多くの人が私の変更に反対しますいくつかのサポート、反対する人は言うでしょう
「システムが安定している場合はビジネス指向である必要があります。何かを変更するとリグレッションが発生する可能性があるため、ビジネスを支持しないでください。」
いつか：
あなたは6ヶ月後にあなた自身の書かれたコードを見るでしょう、常にあなたはこれでいくつかの改善の機会を見るでしょう
サポートする人は言うでしょう：
これは継続的な改善であり、システムはより安定します
だから私はあなたの人々がどう思うか知りたいです
該当する場合は、単体テスト（または、エッジケースをカバーするためにいくつか）を記述します。これにより、リファクタリングを行う自信が得られ、何も壊れていないことがわかります。
もちろん、コードが緊密に結合されている場合（またはスパゲッティ！）、それは問題になります。
壊れていない場合は修正しないでください-ラップしてください。実装を変更せずに、モジュールを可能な限り分離します。本当に必要が生じたとき/必要に応じて、それらに触れる（修正、改善）必要があります。
私の意見では、古いコードが完璧に見えない場合は、その記述方法が現在のタスクに干渉しない限り、修正しないでください。
ほとんどのコードはひどく書かれています。それは事実の問題です。品質の価値を完全に理解し、この品質レベルを達成および維持するためのアプローチについて合意した完全なチームに属していない場合、最適化によって全体像が変わることはありません。あなたは今何かを修正するかもしれませんが、次の人は再び物事を台無しにするでしょう。
私は、この業界では、壊れていない場合は、正当な理由がない限り、修正しないでくださいという結論に達しました。
アプリケーションを完全に理解している場合、または包括的な単体テストがあり、非生産的な環境でアプリケーションをテストする時間があれば、それを試してください。それ以外の場合は、必要なときにのみ実行してください。
どちらも正しく、簡単な方法はありません。
問題が発生したときに修正しなければ、すべての問題が修正されるわけではありません。
現在取り組んでいる問題に 100% 関係のない修正で何かを壊すと、人々はあなたを嫌うでしょう。
一方、無害なコード (または、無害に見えるコード) を修正して予期しない方法で壊れた場合は、価値のあるもの、つまり脆いコードを発見したことになります。脆弱なコードは、通常、誰もあえて触れようとしないものです。しかし、製品をより安定させるには、そのようなコードを取り除く必要があります。この道の最初のステップはそれを見つけることです。
このような修正は、チーム内で多くの「不必要な」摩擦を引き起こすことを認めざるを得ません。壊れやすいコードに触れると、人々は怖がって怒鳴るでしょう。多くの場合、このコードは顧客の顔に吹き付けられるため、さまざまな方向から熱がこもります。
したがって、どれだけの痛みを引き起こしたいか、そして何に耐えたいかによって異なります。遭遇したときにすべてを修正すると、年末までにコードが改善されます。しかし、一日の終わりまでに悪化することがよくあります。
「壊れていない場合は修正しないでください」というすべての回答を2番目にしたいのですが、関連するリンクを付けて...
絶対にやってはいけないこと、パート 1 - Joel Spolsky
本質的には、理解できないコードが実際には必要なバグ修正であり、理解する機会がない場合があります。
一方で、すでに多かれ少なかれ機能しているコードを変更すると、問題が発生するリスクがあり、簡単にすべてを消費するタスクになる可能性があります。
一方、悪いコードを維持する負担のために、物事を壊すことを恐れて悪いコードを放っておくと、新しい開発が妨げられる可能性があります。
Joel Spolsky が指摘しているように、コードは複雑な特殊なケースに対処しなければならないため、見栄えが悪くなることがあります。コードが本当に悪いために悪いように見えることもあり、コードを書き直すことで、そこにあることさえ知らなかったバグを修正できます。コード ベースの経験は、どのコードがどれであるかを判断するのに役立ちます。
Boy Scout Check-Insの中で、Jeff Moser は「キャンプ場を常に自分が見つけたよりもきれいにする」という考えについて論じています。すべてを修正できない場合でも、常にコードベースを見つけたときよりもクリーンなままにしておきます。これらの小さな改善は、時間の経過とともに積み重なっていきます。
この回答で述べたように、単体テストは良いことです。 このトピックに関する優れたリソースは、Michael Feathers 著のWorking Effectively with Legacy Codeです。
私は個人的に、必要なタスクをこなすよりも、物事を修正することに時間を費やす傾向があります。残念なことに、簡単な問題のように見える問題を修正し始めて、解決しなければよかったと思うほどの混乱を解き始めるのは、あまりにも簡単です。
私は逆の立場の人たちとも仕事をしてきました。
多くの場合、将来の作業を容易にするために「何かを正しくする」ことに何年も費やすことができ、コードが将来再利用されることは決してないことがわかります。
主なことは、チーム内でバランスの取れた意見を持ち、他の人と定期的に話し合い、最終的にはプロジェクトの要件を満たすことだと思います。請求書を支払うのは顧客だからです。
見つけた問題については建設的に考えてください - 穴を開けるだけではいけません! チーム コード レビューは、時間の経過とともに悪いコードを改善するのに役立ちます。
「TODO」コメントで悪いコードをマークし、後で修正するために戻ってくることをお勧めします。少なくとも、その場で必要のない修正に (おそらく) 時間を無駄にすることなく、潜在的な問題領域のフラグを立てることができます。