一貫性を保つために間違った方法でコーディングし続けますか？
簡単にするために、AwesomeAppとBadAppの2つのアプリケーションを保守する責任があるとしましょう（私はもっと責任があり、実際の名前ではありません）。
AwesomeAppは、私がチームの他のメンバーと一緒に取り組んできたグリーンフィールドプロジェクトです。それは、すべての派手な流行語、マルチレイヤー、SOA、SOLID、TDDなどを使用してコーディングされました。それは私たちがチームとして行きたい方向性を表しています。
BadAppは、長い間使用されてきたアプリケーションです。アーキテクチャには多くの罪があります。つまり、すべてが緊密に結合されており、コンパイラから循環依存エラーが発生することは珍しくありません。単体テスト、大きなクラス、重複コードなどはほとんど不可能です。 AwesomeAppによって確立された標準に従ってアプリケーションを書き直す計画がありますが、それはしばらくの間起こりません。
BadAppにアクセスしてバグを修正する必要がありますが、正しく考えているものをコーディングするのに何ヶ月も費やした後、悪いコーディング慣行を永続させたくありません。ただし、AwesomeAppのコーディング方法は、BadAppのコーディング方法とは大きく異なります。 「正しい」方法を実装すると、アプリケーションを保守しなければならない他の開発者が混乱するのではないかと心配しています。
質問：アプリケーション内の残りのコードとの一貫性を保つために間違った方法でコーディングを続ける方が良いですか（置き換えられることを知っています）、またはそれは非常に異なっているので混乱を引き起こす可能性があることを理解して正しい方法でコーディングする方が良いですか？
あなたに例を与えるために。いくつかの機能を持つ大きなクラス（1000行以上）があります。関数の1つは、列挙された値に基づいて日付を計算することです。現在、この関数はさまざまな計算をすべて処理します。この関数は、クラス内の他の機能に依存していません。それは自己完結型です。関数を（少なくとも）小さな関数に分割し、それらを独自のクラスに入れ、それらのクラスを（多くても）インターフェイスの背後に隠し、ファクトリパターンを使用して日付クラスをインスタンス化したいと思います。クラス内でそれをより小さな関数に分割した場合、既存のコーディング標準に従います。追加の手順は、SOLIDの原則のいくつかに従って開始することです。
一貫性は毎回品質よりも価値がありません。 BadAppの他の開発者が適切なコーディング方法を知らない場合は、トレーニングするか、解雇してください。
または、上司がこれら2つの選択肢を検討しない場合は、ヘッドハンターに連絡してください。
編集：BadAppに取り組んでいる他の開発者が良いコードに問題があるだろうとあなたが示唆していたという私の印象でした。そうでない場合は、まあ、本当にうまくコーディングを開始しない理由はありません。一貫性は、価値のあるものと一貫している場合にのみ価値があります。
BadAppを「修正」する際の危険は、BadApp V2.0の時期になるまで、GoodAppに費やす時間と労力を浪費することだと思います。
私は...するだろう：
- チームミーティングを開き、2つの違いを列挙します。これは、すべての人（「古い学校の生徒」を含む）が良いものを購入するのに役立ちます。
- 古いもの（機能している場合）の一部をそのままにして、修正が必要なものについて自分でパンくずリストを残すことを認めます。チケットシステムを使用することも、コードで「TODO」タイプの拡張コメントを使用することもできます。時間が経つと、これらは蓄積され、移行のバグは少なくなります。
- BadAppのやり直しが来ると、経営陣はあなたが上で特定したことに基づいて適切なリソースをコミットします...笑私はそれをタイプしたいだけです、まっすぐな顔でそれを言うことはできませんでした:-)
私があなたの代わりにいた場合は、チームにコードのリファクタリングに集中するか、少なくともコードのリファクタリングを担当する人だけを割り当てることをお勧めします。それが長期的に見返りをもたらすことはかなり明白なはずです。
修正することを恥ずかしがらないでください壊れたコード！
コードを常にリファクタリングすることは、必ずしも良いことで生産的であるとは限りません。私には優秀なプログラマーである同僚がいましたが、彼は自分が取り組んでいたアプリを完成させることができませんでした。新しいバグが発生するたびに、彼はプログラムに多くの障害を見つけ、バグを修正するためにいくつかの構造を変更しようとしました。彼はやがて解雇された。
バグを修正するためだけに必要な時間よりも30〜40％長い時間かかる変更がある場合は、コードを変更すると思います。あなたとあなたのチームがコードを完全にリファクタリングする時間/人を見つけるまでに、多くのことがすでに行われているので、それははるかに簡単になります。そのアプリに新しいコードを追加する場合は、適切に追加してください。誰かがそれを理解しないことを恐れないでください。
しかし、すべてのバグで大きなコードを書き直そうとすると、どこにも行き着きません。小さな変更を加えて大きなリファクタリングを待つか、古い厄介だが機能しているコードに触れない方がよいでしょう。
結局のところ、BadAppのコスト分析で、コードをより良い標準に更新する価値があるかどうか、またはアプリケーションを完全に書き直す方が良いかどうかを確認します。または、BadAppの機能の一部を実行し、残りを書き換え/更新するための既製のソリューションがある場合があります。
1つのアプローチは、開発者にBadAppのコードを調べてもらい、何を変更/更新する必要があるかを概説することです（これは、コスト分析の一部または結果である可能性があります）。そのリストを保持し、BadAppに入る必要があるときはいつでも、書き換え関数の1つを使用してそれを完了します。 BadAppを標準に更新するための期間を延長しますが、最終的には少なくともMediocreAppになります。