歴史的に成長したソフトウェアの名前付きアンチパターンはありますか？
複数の開発者がシステムに新しい機能を追加したばかりで、アーキテクチャ全体を監視したり、リファクタリングを行ったりしていない、歴史的に成長したソフトウェアシステムを表すアンチパターンはありますか？
これは、管理/顧客が常に新機能を要求し、誰も何かをリファクタリングするのではなく、他の開発者が以前に行ったことを追加するときに起こると思います。
理由としては、開発者がソフトウェアシステムに圧倒され、現在の動作を実際に理解していないため、最後にコードを追加/接着する（コードをリファクタリングして変更するのではなく）ことが考えられます。
したがって、時間の経過とともに、システムのメンテナンスはますます難しくなっています。
（全体のデザインを考えずに機能を追加するだけで作られた車のように、プログラミングの関係者にこれをより明確にするために、この種のアンチパターンの写真があるかどうか疑問に思います。誰かが牽引する必要があるように後退中にトレーラーを運転し、エンジニアが牽引バーを車の前部に溶接するだけです。作業は完了しましたが、カウルはもう開きません。）
技術的負債を参照します。
私たちは皆、時間をかけて開発した製品に技術的負債を負っています。リファクタリングは、この技術的負債を削減するための非常に一般的で効果的な方法の1つですが、多くの企業は技術的負債を決して返済しません。これらの企業は、今後数年間でソフトウェアが非常に不安定になる傾向があり、技術的負債が非常に深刻になるため、その方法で支払うのに時間がかかりすぎるため、段階的に支払うことはできません。
技術的負債は、負債の同じ振る舞いに従うため、用語があります。あなたは借金を手に入れ、その借金を返済せずに（機能を作成して）支出し続ける限り、それは成長するだけです。借金のように、それが大きくなりすぎると、全面的な書き換えなどの危険なタスクで完全に取り除こうとする可能性があるポイントに到達します。また、実際の借金と同様に、特定の時点で発生するため、支出（機能の作成）を完全に妨げます。
cohesionは、ミックスで別の用語を使用するために、システム、マイクロからラインレベル、またはマクロをどれだけ適切に参照しているかを示します。システムレベルに、一緒に収まります。非常にまとまりのあるシステムでは、すべての部品が非常にうまく組み合わされ、1人のエンジニアがすべてを書いたように見えます。上記のコードを最後まで貼り付けている誰かを参照すると、そのシステムの結束に違反することになります。
技術的負債の管理
技術的な負債を管理する方法はたくさんありますが、実際の負債と同様に、最善の方法は頻繁に支払うことです。残念ながら、実際の借金のように、短期間でより多くを獲得する方がよい場合があります。たとえば、機能の市場投入までの時間が、収益を2倍または3倍にする場合があります。トリッキーな部分は、これらの競合する優先順位を比較検討することと、負債 [〜＃〜] roi [〜＃〜] が特定の機能に対して価値がない場合とそうでない場合を識別することです。
したがって、短期間で借金を積み立てることは価値がある場合がありますが、それはまれなケースであり、すべての借金と同様に、期間が短いほど良いです。したがって、最終的に（できればquickly）技術的負債が発生した後、それを返済しなければなりません。これらは一般的なアプローチです：
- リファクタリング
- これにより、実装の途中または完了後に誤って配置されたことがわかったコードのビットを取得し、それらをcorrectの場所（またはいずれにせよ、より正しいものです）。
- リライト
- これは破産のようなものです。それはスレートをきれいに拭き取りますが、何もないところから始めて、同じ間違いを犯したり、もっと大きな間違いをしたりするあらゆる機会があります。技術的負債に対する高リスク高報酬アプローチですが、時にはそれがのみオプションです。それは多くの人が言うよりもまれなケースですが。
- アーキテクチャの概要
- これはより積極的な技術的債務返済アプローチです。これは、技術的な詳細に対して権限を持つ誰かに、プロジェクトの計画とスケジュールの実装に関係なく停止させ、技術的負債が少なくなるようにすることで行われます。
- コードフリーズ
- 変更のコードをフリーズすると、借金が増えたり下がったりしない余地が生まれます。これにより、技術的負債を削減するためのアプローチを計画して、アプローチで最高のROIを期待できます。
- モジュール化
- これは、アーキテクチャの概要を採用してモジュラーシステムを持つか、リファクタリングを使用してそのいずれかに移行する場合にのみ利用できるTier 2のアプローチに似ています。モジュラーシステムを使用している場合は、システムのすべての部分の借金を孤立した方法で支払うことができます。これにより、partialリライト、partialリファクタリングを次のように実行できます。また、分離はシステム全体に広がるのではなく、機能が導入された領域でのみ債務を維持するため、技術債務の発生率を最小限に抑えます。
- 自動テスト
- 自動テストは、システムの問題点を特定するのに役立つため、自動化されたテストは技術的な負債の管理に役立ちます。できれば、それらの領域の負債が非常に大きくなる前でも、エンジニアがそれらの危険な領域をエンジニアに認識させることができますまだ実現していないかもしれません。さらに、自動化されたテストを取得した後は、多くを壊すことを心配することなく、より自由にリファクタリングできます。開発者が物事を壊さないのではなく、物事を壊したときが見つかるので、負債の多いシステムで手動テスターに依存すると、問題を発見するための実績が不十分になる傾向があります。
あなたの説明は、Foote and Yoder'sBig Ball of Mudに適合します：
過去数年にわたり、多くの著者が高レベルのソフトウェアアーキテクチャを特徴付けるパターンを発表してきました...理想的な世界では、すべてのシステムが1つ以上のそのような高レベルのパターンの模範となるでしょう。しかし、これはそうではありません。実際に主流となっているアーキテクチャについては、まだ議論されていません： BIG BALL OF MUD 。
泥だらけの大きなボールは、不規則に構造化された、広大な、ずさんな、ダクトテープおよびベイルワイヤー、スパゲッティコードジャングルです。私たちは皆それらを見てきました。これらのシステムは、無秩序な成長と繰り返しの好都合な修理の紛れもない兆候を示しています。情報は、システムの離れた要素間で無差別に共有されます。多くの場合、ほとんどすべての重要な情報がグローバルになるか、複製されます。システムの全体的な構造が十分に定義されていない場合があります。もしそうなら、それは認識できないほど侵食されたのかもしれません。建築的感性の断片を持つプログラマーは、これらのクワミアを避けます。アーキテクチャに関心がなく、おそらく、これらの障害のある堤防の穴にパッチを適用するという日常の雑用の慣性に慣れている人だけが、そのようなシステムで作業することに満足しています...
システムがなぜBUD OF BUD OF MUDになるのですか？時々、大きくて醜いシステムが THROWAWAY CODE から現れることがあります。 THROWAWAY CODEは、1度だけ使用され、その後破棄されることを意図した、汚いコードです。ただし、このようなコードは、構造がカジュアルで、ドキュメントが不十分または存在しないにもかかわらず、多くの場合、独自の機能を果たします。動作するので、なぜ修正するのですか？関連する問題が発生した場合、適切な一般的なプログラムを最初から設計するのではなく、この作業コードを適切に変更することが、問題に対処する最も早い方法である可能性があります。時間の経過とともに、単純な使い捨てプログラムがBUD OF BUD OF MUDを生み出します。
明確に定義されたアーキテクチャを備えたシステムでさえ、構造的な侵食を受けやすいです。成功したシステムが引き付ける要件の変化の容赦ない猛攻撃は、その構造を徐々に弱体化させる可能性があります。整頓されていたシステムは PIECEMEAL GROWTH として次第に大きくなり、システムの要素が制御されない方法で徐々に広がっていきます。
そのような無秩序な増加が衰えずに続く場合、システムの構造がひどく危険にさらされ、放棄する必要がある場合があります。衰退する近所と同様に、下向きのスパイラルが発生します。システムがますます理解しにくくなるため、メンテナンスはより高価になり、困難になります。良いプログラマはそこで働くことを拒否します。投資家は資本を引き出します。それでも、近隣地域と同様に、この種の衰退を回避し、さらには逆転させる方法があります。宇宙の他のものと同様に、エントロピー力を打ち消すにはエネルギーの投資が必要です。ソフトウェア gentrification も例外ではありません。ソフトウェアでエントロピーを阻止する方法は、それをリファクタリングすることです。リファクタリングへの継続的な取り組みにより、システムが大きな泥の泥沼に沈むのを防ぐことができます...
- ...泥の最も効果的な敵の1つは日光です。複雑なコードを精査矢印にさらすことで、そのリファクタリング、修復、およびリハビリの準備が整います。 コードレビュー は、コードを日光にさらすために使用できる1つのメカニズムです。
