コードのメンテナンス：一貫性を保つために新しいコードを拡張するときに悪いパターンを維持するかどうか。
プロジェクトの既存のモジュールを拡張する必要があります。私はそれが行われた方法が好きではありません（コピー/貼り付けられたコードのような多くのアンチパターンが関与しています）。多くの理由で、完全なリファクタリングを実行したくありません。
したほうがいい：
- 次のメンテナの混乱を避け、コードベースとの一貫性を保つために、私が間違っていると感じても、既存の規約を使用して新しいメソッドを作成しますか？
または
- コードに別のパターンが導入されている場合でも、気分が良くなるものを使用してみてください。
Precisonは最初の回答後に編集しました：
既存のコードは混乱ではありません。理解しやすいです。しかし、優れた設計で回避できる多くのボイラープレートコードが導入されています（その結果、コードが追跡しにくくなる可能性があります）。私の現在のケースではそれは古き良きJDBC（スプリングテンプレートインボード）DAOモジュールですが、私はすでにこのジレンマに遭遇しており、他の開発者のフィードバックを求めています。
時間がないのでリファクタリングしたくありません。そして、時間が経っても、完全に機能するモジュール全体がリファクタリングを必要とすることを正当化することは困難です。リファクタリングのコストは、そのメリットよりも重いでしょう。覚えておいてください。コードは面倒なものや複雑なものではありません。そこではいくつかのメソッドを抽出できず、ここで抽象クラスを紹介します。それはデザインの欠陥です（極端な「Keep It Stupid Simple」の結果だと思います）
だから、質問はそのように尋ねることもできます：
あなたは、開発者として、簡単な愚かな退屈なコードを維持することを望みますかORあなたの場所で愚かな退屈なコードを実行するヘルパーを用意しますか？
最後の可能性の欠点は、いくつかのことを学ぶ必要があり、おそらく完全なリファクタリングが完了するまで、簡単な愚かな退屈なコードも維持する必要があるということです）
リファクタリングは小さなステップで行うのが最適です。できれば、コードをカバーする単体テストがある場合に限ってください。 （まだテストがない場合は、最初にテストを作成するように努め、それまでは、最も単純で最も簡単な、できれば自動化されたリファクタリングに固執してください。これに対する大きな助けは です。レガシーコードを効果的に使用する Michael Feathersによる。）
一般に、コードに触れるたびに少し改善することを目指します。 ボーイスカウトルール（ Robert C. Martinによる造語 ）に従って、コードを見つけたよりもクリーンなままにします。新しいコードを追加するときは、既存の不良コードから分離するようにしてください。例えば。長いメソッドの途中に埋め込むのではなく、代わりに別のメソッドの呼び出しを追加して、そこに新しいコードを配置します。このようにして、既存のコードベース内のクリーンな（より多くの）コードのアイランドを徐々に大きくしていきます。
更新
リファクタリングのコストは、そのメリットよりも重いものになります。[...]あなたは、開発者として、簡単で愚かな退屈なコードを維持することを好みますかORあなたの場所で愚かな退屈なコードを実行するヘルパーがいますか？
ここで重要なポイントはどれかを強調しました。リファクタリングのコストと利点を評価することは常に価値があります前にそれに飛び込みます。あなたの場合のように、私たちのほとんどはリファクタリングのための限られたリソースを持っているので、私たちはそれらを賢く使用する必要があります。貴重な小さな時間をリファクタリングに費やして、最小限の労力で最大のメリットをもたらします。
創造的な心として、もちろん、完璧で美しくエレガントなコードを作成し、自分の理想に似ていないすべてのものを書き直すことを好みます:-)しかし、実際には、ユーザーの実際の問題を解決するソフトウェアを作成するために支払われます。長期的に彼らのお金の最大の価値を生み出すことを考えるべきです。
リファクタリングの利点は、コードを長期的に理解、維持、修正、および拡張するための時間と労力が十分に節約された場合にのみ現れます。したがって、コードの一部（醜いとしても）がほとんどまたはまったく触れられない場合、既知のバグはなく、予見可能な将来、触れる必要のある将来の機能については知りません。安心して。
リファクタリングする時間がないため、コードは保守可能であるため、一貫性を維持してください。次回は、見積もりにリファクタリングを含めるようにしてください。
整合性は優先度が高い。明らかに、正しい心の中の誰もが、どこにもコピー貼り付けされたボイラープレートではなく、エレガントなDRYソリューションをどこでも好むでしょう、butは同じコードベースで2つの異なるアプローチを一貫して適用することを本当に望んでいますか？誰かがさらにスマートなソリューションを発明し、それを一貫して適用しない場合はどうなりますか？同じことを行う3つの異なる方法があります。
開発者が何かを行うための「より良い方法」を見つけたものの、コードベース全体に一貫してそれを適用していないことに起因する、多くの厄介なコードを見てきました。時間の経過とともに新しいパターンを徐々に適用する計画的かつ調整された戦略の一部である場合、それは機能する可能性がありますが、一貫して実装されていないすべてのパターンには、システム全体を悪化させるリスクがあります。
おそらく、各ステップをコードベース全体に一度に適用できるように、小さなステップでリファクタリングを検討することもできます。例えば。各反復でボイラープレートの小さな部分をヘルパー関数に抽出します。時間の経過とともに、ヘルパークラスのすべての定型文が作成されます。設計されていなかったために見た目が醜く見えるかもしれませんが、すべてのコードが1か所にあるので、今は修正できます。
一貫性を保つことは、周囲のコードの状態が良好な場合にのみ、次の開発者を支援します。手元のコードを理解し、変更を追加するための適切な「拡張ポイント」を見つけるのにかかった時間を考えてください。現在の傾向に従う場合、次の人は既存のコードと新しいコードを理解して、変更を加える必要があります。
コードを意味のある関数にリファクタリングすると、次の人は何が起こっているのかを理解するのが簡単になり、変更を追加するための労力を減らす必要があります。このように考えてください。次の男はあなたであると仮定します。このコードブロックに再度アクセスしたときに何を見たいと思いますか、今見ているのと同じ混乱、またはより論理的に構築されたものは何ですか？
重複コードを排除するリファクタリングは優れたリファクタリングであり、締め切りが迫っていない限り延期すべきではありません。 1回のリファクタリングに費やされた時間は、将来の実装で獲得された時間で簡単に埋め合わせることができます。リファクタリングのおかげで内部の仕組みが見えなくなったので、理解するのが容易になり、理解するのが難しくなります。
私の意見では、リファクタリングされたコードは従うのが難しいというのはよくある誤解です。これは通常、リファクタリングされている結果に精通しているだけの人であり、リファクタリングされた結果ではありません。新規参入者にとって、リファクタリングされた結果はより明確になります。
バグ/機能は後で中央の場所で修正/実装でき、アプリケーションのすべての場所で自動的に利用できます。これは通常非常に過小評価されている巨大な利益です。一般に、コンポーネントの完全なリファクタリングにはそれほど時間がかかりません。 （数か月ではなく数日）これをバグによって失われた時間と比較すると、リファクタリングされた可能性のあるコードを理解する必要があるため、リファクタリングのコストは最小限になります。
PéterTörökの返答に関する更新：「時間がかかるため」リファクタリングを延期することにより、後でリファクタリングする時間が増加しませんか？リファクタリングは、頻繁に実行されても、それほど長くはかかりません。
製品に何も追加せず、製品に何も追加しないコードを数日かけて作成することは上司にどのように説明するかは難しく、まったく別の問題です。 :)
簡単に拡張できる独自のスタイルで新しいコードを導入しながら、古いコードのファサードとして機能する新しいインターフェイス/クラスを作成できませんか？
あなたは、開発者として、あなたの場所で愚かな退屈なコードを実行するヘルパーを作るために、簡単な愚かな退屈なコードORを維持したいと思いますか？
改訂された質問が理解できません。私自身、ほとんどの人は「愚かな退屈なコード」を維持したくないと思います。ヘルパーの意味がわかりません、ごめんなさい。
ポスターは、現時点で大きな変更を加えないことで、自分の質問に答えました。良い選択。開発者がビジネスに最適なものを知っているという傲慢さに問題があります。ずるいでの大きなリファクタリング...あなたはあなたの上司よりよく知っているので？有能なマネージャーなら誰でもメリットを比較検討できます。
リファクタリングが選択肢ではない場合、問題は、それを行うための正しい時間、場所などについての議論になります。一貫性は非常に重要です。しかし、存続期間の長いコードは「更新」の恩恵を受けることがよくあります。他の人がこれについて議論しています...
今後も正しく実行してください。カットアンドペーストの代わりに関数を使用します。それはリファクタリングを必要としませんが、それはあなたに将来のリファクタリングのための基礎のスタートを与えます。