歴史的に成長したソフトウェアに名前付きのアンチパターンはありますか？[閉まっている]

複数の開発者がシステムに新しい機能を追加しただけで、アーキテクチャ全体を実際に監視したり、リファクタリングを実行したりしない、歴史的に成長したソフトウェアシステムを説明するアンチパターンはありますか？

これは、管理者/顧客が絶えず新しい機能を要求し、誰も何もリファクタリングせず、他の開発者が以前に行ったことに追加するだけの場合に起こると思います。

開発者がソフトウェアシステムに圧倒されており、現在どのように機能するかを実際に理解していないため、コードをリファクタリングして変更するのではなく、最後にコードを追加/接着するだけの場合もあります。

そのため、時間の経過とともに、システムの保守がますます難しくなっています。

（これらの種類のアンチパターンの写真は、プログラミング全体に誰もがこれをより明確にするためにありますか？全体的なデザインを考えずに機能を追加するだけで構築された車のように。後方に移動しながらトレーラーを牽引し、エンジニアが車両の前面に牽引バーを溶接するだけです。作業は完了しました。しかし、カウルはもう開きません。）

あなたは技術的な負債について言及します。

私たちは皆、時間の経過とともに開発する製品に技術的負債を生じます。リファクタリングは、この技術的負債を減らす非常に一般的かつ効果的な方法の1つですが、多くの企業は技術的負債を返済することはありません。これらの企業は、将来的にソフトウェアが非常に不安定であることに気付く傾向があります。

技術的負債には、負債と同じ振る舞いに従うため、用語があります。あなたは借金を受け取り、あなたが支出を続け（機能の創造）、その借金を返済しない限り、それは成長するだけです。借金のように、それが大きすぎると、全面的な書き換えのような危険なタスクで完全にそれを流したいと思うかもしれません。また、実際の借金のように、一定のポイントに達すると、（機能を作成するために）費やす能力を完全に妨げます。

ミックスで別の用語をスローするために、凝集度とは、システム、ラインレベルへのマイクロ、またはシステムレベルへのマクロがどれだけうまく適合するかを指します。高度に凝集したシステムでは、すべての部品が非常にうまく適合し、1人のエンジニアがすべてを作成したように見えます。上記の誰かが自分のコードを最後まで接着するだけであるということは、そのシステムの結束に違反することになります。

技術債務の管理

技術的な負債を管理するには多くの方法がありますが、実際の負債のように最善のアプローチはそれを頻繁に返済することです。残念ながら、実際の借金のように、短期間でより多くを稼ぐほうが良い場合があります。たとえば、機能の市場投入までの時間が収益の2倍または3倍になる場合があります。トリッキーな部分は、これらの競合する優先順位を評価することと、特定の機能に対して負債ROIが価値がない場合とそうでない場合を識別することです。

したがって、短期間借金を積む価値がある場合もありますが、それはめったにありません。すべての借金と同様に、期間が短いほど良いです。そのため、最終的に（できれば迅速に）技術的な負債が生じた後、それを返済する必要があります。これらは一般的なアプローチです。

• リファクタリング
  • これにより、実装の完了中または完了後に誤って配置されたと認識されたコードの一部を取得し、それらを正しい場所（またはとにかく正しい場所）に配置できます。
• リライト
  • これは破産のようなものです。それはスレートをきれいに拭き取りますが、あなたは何もないところから始めて、同じ間違い、あるいはもっと大きな間違いをするあらゆる機会を持っています。技術的負債に対する高リスクで高価値のアプローチですが、それが唯一の選択肢である場合もあります。多くの人が言うよりも、それはめったにありませんが。
• アーキテクチャの概要
  • これは、より積極的な技術的債務返済アプローチです。これは、プロジェクトの計画やスケジュールに関係なく、技術的な詳細について権限を持つ誰かが実装を停止し、技術的な負債が少なくなるようにすることで行われます。
• コードフリーズ
  • 変更のコードを凍結すると、借金が増えたり減ったりしない部屋を確保できます。これにより、技術的な負債を減らすためのアプローチを計画する時間を確保でき、アプローチのROIが最大になることを期待できます。
• モジュール化
  • これは、すでにアーキテクチャの概要を使用してモジュラーシステムを使用するか、リファクタリングを使用して1つに移行する場合にのみ使用可能なティア2アプローチのようなものです。モジュラーシステムを使用している場合は、システム全体を個別に借金することができます。これは、あなたがすることができ、部分的に再書き込み、部分的なリファクタリングを、だけでなく、アイソレーションが唯一のシステム周りの普及に対立するものとしての特徴は、中に入ったそれらの領域に借金を保つため、レート技術的負債の計上を最小限に抑えます。
• 自動テスト
  • 自動テストは、技術的な負債の管理に役立ちます。システム内のトラブルスポットを特定するのに役立つためです。できれば、それらの領域の負債が非常に大きくなる前に、しかし、エンジニアに危険な領域を認識させることができます。まだ気付いていないかもしれません。さらに、自動化されたテストを取得すると、あまりにも多くのことを心配することなく、より自由にリファクタリングできます。開発者が物事を壊さないからではなく、物事がいつ破られるかを見つけるので、非常にお世話になっているシステムの手動テスターに​​依存することは、問題を見つけるための実績が乏しい傾向があります。

あなたの説明はFooteとYoderのビッグオブマッドに適合します。

過去数年にわたって、多くの著者が...高レベルのソフトウェアアーキテクチャを特徴付けるパターンを提示してきました...理想的な世界では、すべてのシステムが1つ以上のそのような高レベルパターンの模範になります。しかし、これはそうではありません。実際に優勢なアーキテクチャについてはまだ議論されていません：BIG BALL OF MUD。

ビッグボールオブマッドは、無秩序に構造化され、広大で、ずさんな、ダクトテープとベイリングワイヤー、スパゲッティコードジャングルです。私たちは皆それらを見てきました。これらのシステムは、無秩序な成長と繰り返された適切な修復の紛れもない兆候を示しています。情報はシステムの遠く離れた要素間で無差別に共有され、ほとんどすべての重要な情報がグローバルまたは複製になります。システムの全体的な構造が明確に定義されていない場合があります。もしそうなら、それは認識を超えて侵食された可能性があります。細心の注意を払ったプログラマーは、これらの泥沼を避けます。建築に無関心で、おそらく、これらの失敗した堤防の穴にパッチを当てるという日々の雑用の慣性に慣れている人だけが、そのようなシステムで作業することに満足しています...

なぜシステムは泥の大きなボールになるのですか？時々、大きくていシステムがTHROWAWAY CODEから出現します。THROWAWAY CODEは、一度だけ使用され、その後破棄されることを意図した迅速で汚いコードです。ただし、そのようなコードは、カジュアルな構造と不十分または存在しないドキュメントにもかかわらず、多くの場合、独自の寿命を取ります。動作するので、なぜそれを修正するのですか？関連する問題が発生した場合、それを解決する最も迅速な方法は、適切に一般的なプログラムをゼロから設計するのではなく、この作業コードを適切に変更することです。時間が経つにつれて、単純な使い捨てプログラムがBIG BALL OF MUDを生みます。

明確に定義されたアーキテクチャを備えたシステムでさえ、構造的な侵食を受けやすい傾向があります。成功するシステムが引き付ける要件の変化の容赦ない猛攻撃は、徐々にその構造を弱体化させる可能性があります。PIECEMEAL GROWTHにより、システムの要素が制御されない方法で無秩序に広がり、かつては整然としていたシステムが大きくなりすぎています。

このような無秩序な増加が衰えずに続くと、システムの構造がひどく損なわれ、放棄しなければならない可能性があります。減衰する近隣の場合と同様に、下向きのらせんが続きます。システムがますます理解しにくくなるため、メンテナンスはより高価になり、より困難になります。優秀なプログラマーはそこで働くことを拒否します。投資家は資本を引き出します。しかし、近隣地域と同様に、この種の衰退を回避する方法、さらには逆にする方法があります。宇宙の他のものと同様に、エントロピー力に対抗するにはエネルギーの投資が必要です。ソフトウェアのジェントリフィケーションも例外ではありません。ソフトウェアでエントロピーを阻止する方法は、リファクタリングすることです。リファクタリングへの持続的なコミットメントは、システムが泥だらけの大きなボールに陥ることを防ぐことができます...

• ...泥の最も効果的な敵の1つは太陽の光です。複雑なコードを精査矢印にさらすと、そのリファクタリング、修復、およびリハビリの段階を設定できます。コードレビューは、コードを日光にさらすために使用できるメカニズムの1つです。