既存の悪い習慣、または古いコードに適合しない良い習慣を使用する方が良いでしょうか？

既存のサードパーティ製ソフトウェアの拡張機能を作成しようとしていたため、そのデータベースは恐ろしく非正規化されていたため、これを考えていました。既存のテーブルを使用して、多数の新しいフィールドを追加する必要がありました。

デザインスタイル（1つの大きなテーブルにあるほとんどすべてのプロパティで構成される）で新しいテーブルを作成するか、新しいテーブルセットを一緒に作成し、トリガーなどの特別なものを使用して、新しいテーブルと古いテーブル。

結局、既存の貧弱なデザインスタイルを使用するという最初のオプションに行き着きましたが、この質問が残されました：既存の悪い慣行に行くのか、既存のコードにうまく合わない良い慣行を実装するのが良いのでしょうか？どちらかを選択する必要がある状況はありますか？

注：これまでの多くの答えは、悪いコードをゆっくりとリファクタリングすることに関係していますが、私はそれをすることができません。コードは私たちのものではなく、ベンダーによって頻繁に更新されます。私はそれの上にのみ構築できます。

次の場合は、より良いデザインを選択する必要があります。

1. 将来のコーディングの大部分を引き継ぐことになります

2. 長期的に見れば、クライアントにとって優れたデザインはそれほど高価ではありません。たとえば、私は年末までに中止されたプロジェクトの複数月の「リファクタリング」を目撃しました。

次の場合は、「同じ悪いスタイル」を選択する必要があります。

1. あなたは助けているだけです。既存のグループを採用して、プロジェクトにパートタイムで参加するだけであれば、それらをより高い設計基準に合わせることができると考えるのは非現実的です。より良いデザインは主観的であり、ほとんどの場合、学習曲線があります。その新しいデザインが他のチームによって学習されない場合、プロジェクトはスタイルのミッシュマッシュで終わり、あなたのより良いデザインされたコードは理解できないので誰も変わらないものの山になってしまうかもしれませんそれ。上記の例では、サードパーティソフトウェアの更新があるとどうなりますか？

2. 「より良い」デザインを犠牲にすることで、目に見えるビジネス上の優位性が得られます。機能Xをひどく追加すると、大きな契約が得られますが、期限を守らないと、何もなくなります。ここで、mgmtと技術チームの歴史的な対立が生じます。家の改修のように、誰かがいつ支払うかを決めなければなりません。最初は、電気なしで生活するか、1年間配管工事をすることで、借金を返済することができます。または、これらのユーティリティを使用することで3倍の費用を支払うことができます。

長い目で見れば、良い慣行を使用することをお勧めします。変更の実装にかかる時間が短縮されるため、時間と労力が節約されます。

可能であれば、良い手順にリファクタリングするための小さな手順を実行します（たとえば、非正規化されたテーブルを正規化されたテーブルに分割し、古いテーブル名のビューを使用するSQLで）。

長い目で言ったことに注意してください-「品質、時間、お金」の三角形もここに適用されます（つまり、2つを選択します）。時間がない場合は、古いプラクティスを使用する必要がありますが、これは問題に追加することを意味し、設計も修正する必要があることを意味します。

作業を続け、悪いデザインのコードを追加し続けると、良いデザインを使用するコードベースになってしまうことはありません。可能な限り、適切なデザインを使用し、適切なデザインにリファクタリングしてください。

まあ、私はそれがそれぞれの場合に非常に依存すると思います。パフォーマンスと設計で許可されている場合は、適切な方法を使用することをお勧めします。しかし、たとえば、そのテーブルがアクセス頻度の高いテーブルである場合、シンクロナイゼーションのトリガーを作成すると、パフォーマンスに悪影響を及ぼす可能性があります。

今、あなたのクライアントはあなたがあなたがより良いデザインを使用したことを見ないでしょう、彼はあなたのソリューションが彼のシステムを遅くしたのを見るだけです。この種の決定は、ケースバイケースで行われるべきであり、経験と判断基準を使用して決定する必要があります。

おそらく正しい選択をしたと思います。

可能な限り、貧弱なデータ設計からアプリケーションコードを分離する必要があります。

テーブルを更新していますか？そうでない場合は、SQLビューを作成して、それらのテーブルをアプリケーションに便利な方法で表示します。SQLビューは比較的簡単に記述でき、アプリケーションコードよりもテストがはるかに簡単です。

レガシテーブルを更新する必要がある場合は、更新を管理するストアドプロシージャの作成を検討してください。書くのはもう少し複雑ですが、すぐにテストできます。

トリガーを使用してデータベースを正規化するときに古いコードの同期を保つには、一時的な場合に適したソリューションがあります。目標は古いコードを変更することですが、サードパーティを扱う場合はうまくいかない可能性があります。スキーマの変更を常に把握する必要があります。

不良コードにますます多くの機能を積み重ねると、継続的な問題が発生します。回避策が標準になります。変更には時間がかかりすぎ、他のバグや制限が導入される可能性があるため、ユーザーはイライラします。プログラマーになりたくないのは、そうすべきではなく、それができないということですか？

一部のコードはそのままにしておくことができます。いつもそんな贅沢があるわけではありません。

ここで技術的な負債を扱っています。要するに、技術的負債は利子を意味し、時間をかけて支払わなければならず、ある時点でそれを返金しなければなりません。

Develloperの時間にはお金がかかるため、技術的負債は実際の負債と同じように見え、実際の費用がかかります。

基本的に2つの主要なソリューションがあり、その間に多くのソリューションがあります。あなたは、その借金を今すぐ払い戻したくないと決めて、利子を払い続けることができます。明らかに、これは長期的にはより多くの費用がかかりますが、すぐに結果を得ることができます。また、その借金を返済することもできますので、返済しない限り、それ以上先に進むことはできませんが、最後には利息はありません。

通常、納期はありますが、納期を守らないと顧客に不信感が生じ、最終的には納期を失うことになります。これは、技術的負債を掘り下げる正当な理由かもしれません。顧客から得たものは、技術的負債を余分に払う価値があると考えます。

最後に、新しい方法論を採用する必要があり、さもなければ、ますます借金が増え、最終的に破産することを知っています（今、人々がゼロからやり直すことにしたとき、またはプロジェクトがひどく失敗したとき）。

既存のコードベースをどのように変更し、時間をかけて新しいプラクティスに移行するかを計画し、毎日変更を少しずつ分散させる必要があります。ある時点で、それらのリファクタリングが他の損失につながる場合、どの損失がより悪いかを考慮し、最良の損失に進みます。

リファクタリングを行わない場合のコストは、時間の経過とともに増加します（これは技術的負債の利益です）。したがって、これが最終的に最もコストのかかる選択になります。

上司が技術的負債の概念を理解していることを確認してください。予防策を講じても、技術的な負債が発生します。ある時点で、それを返金するために使用されるお金。意図的に技術的負債を作成する場合、その正当な理由があり、その負債を投資と見なす必要があります（実際の負債と同じように）。それ以外の場合は、意図的に技術的負債をしないでください。

DBを進化させ、それらの進化を展開する方法論に興味があるかもしれません：http ://richarddingwall.name/2011/02/09/the-road-to-automated-database-deployment

ちなみに、それは難しい作業なので、幸運を祈ります。それだけの価値がある！

これは典型的な問題です：「今すぐ、または後で仕事の恩恵を享受する必要がありますか？」そして、私はその答えに一般的な解決策があるとは思わない。そのような決定に関与するすべての要因（技術的および人間的）を知っているのはあなただけです。

しかし、あなたの問題は興味深い質問を提起します：

コードの均一性をより重視するために、自動コードリファクタリングは十分に進歩していますか？

最終的に、悪いデザインは変更されるか、死ぬはずです。または、それは悪いデザインではありません。ここでの本当の問題は、リファクタリングのコストについてです。あなた（またはあなたの雇用主）は今、代価を払おうとはしておらず、現在の技術状態ではこれまでに望んでいない可能性が高いことはあなたの質問から明らかです。

ただし、コードのリファクタリングの自動化はいくつかの進歩を遂げています。コンパイラが今日バイナリを最適化できる場合、明日コードを最適化しないだろうと言うのは誰ですか？ある時点で、いくつかのツールが登場し、開発者とデザイナーがコードを非常に簡単にリファクタリングして、新しい要件に適応できるようになります。結局のところ、レガシーコードの処理は、今日の最大の課題の1つです。

そのようなツールがこれまでに存在する場合（既に存在することは驚くことではありません）、そのような決定を行う際に考慮に入れておくとよいでしょう。

良い習慣は常に悪いものに勝ります。コードベースに間違った方法でコードが散らばっている場合は、同じ方法で自分のものを単にカーゴカルトするのではなく、適切にコードを書いてから、正しい方法で他の人を教育しようとする必要があります。