コンピュータプログラムが大きな泥だんごに変わる原因は何ですか？このアンチパターンから回復することは可能ですか？適用できる実証済みのリファクタリング方法はありますか？
3437 次
7 に答える
26
大きな泥だんごは通常、次のいずれかの理由で発生します。
要件の変更-あなたは1セットの要件でソリューションを設計しますが、これは時間の経過とともに変化し、現在は、わずかに異なる要件で同じ製品を使用したい別の対象者に対応している可能性があります。これらの要件を同じ製品に焼き付けると、BBOMになります。
開発者の変更-元の製品は、保守またはさらなる開発のために製品を「引き継ぐ」まったく新しい開発者のセットには完全には明らかではない、特定の設計およびアーキテクチャの前提を持つ開発者のセットによって作成されました。新しい開発者は独自の仮定を立て、時間の経過とともに、製品は保守不可能なジャンクの山に劣化します。
無能-開発者（アンチパターンに気づいていない）、管理者（要求が厳しすぎる、製品に関する知識が不足している）、またはユーザー（彼らは本当に必要なものを知らない）。これを解決するのは難しいです。
場合によっては、最善の解決策は、新しい要件に対応するアプリケーションを単に書き直すことです。しかし、これは通常、最悪のシナリオです。面倒な解決策は、すべての新しい開発を停止し、一連のテストを作成してから、ソリューション全体を再設計および再設計することです。ただし、製品のサイズによっては、これには数年かかる場合があります。
于 2009-06-23T02:50:01.513 に答える
8
私が遭遇したBBOMは通常、ダーウィンのプロセスで有機的に作成されました。これは次のようになります。
最初は、システムが作成され（設計されていない）、文書化が不十分です。
元のリソースは他の場所でさらに大混乱を引き起こすため、この「レガシー」システムのオーラルヒストリーすらありません。
新鮮な血が持ち込まれます。これらの開発者は、さまざまなシステムパーツの動作を明らかにしようとしますが、尾、脚、体幹を1つずつつかんだときに、何人かの盲人が象を理解しようとしているようなものです。彼らは変更を加えますが、彼らに本当に自信を持っていることは決してありません。
このように、システムはブラインド自然淘汰によって「進化」しますが、これと並行して、レーダー画面の下にとどまるために、もちろん顧客のインストールで表面化するまで、最も手に負えない再現不可能なバグが存続します。
于 2009-09-30T14:40:02.840 に答える
2
私はいつも（BBOM）という用語を、「すべてがすべてに依存している」コードベースに起因し、変更したいコードを見つけるのが難しく、変更を加えると、すべてを変更しなければならなくなることになります。それを再び機能させる場所。変更された単一のクラス/ファイルをテストするには、コードベース全体が必要です。ボブおじさんはこれをモーニングアフターシンドロームと呼んでいます（ここでは非周期的依存性の原則の下で）。
基本的な依存関係の制御がない場合、コードベースがBBOMに移行することはほぼ避けられません。これは、現在編集しているコードしか表示されない開発者がコードベースを実行できないためです。
于 2009-09-30T18:10:24.283 に答える
2
私の場合、私のソフトウェアの1つの要素がこのパターンに陥っています。これは、約2年前の「一時的な解決策」であり、書き直しを犠牲にして常に新しい機能が追加されていました（常に緊急性があります）。
それが管理上の苦痛を引き起こさないのであれば、彼らはそれを変える動機がありません。「はい、来月時間があれば書き直すことができますが、今この場合に機能する必要があります」。新機能が登場するとすぐに、書き直しは忘れられます。
私は2年間、それは貧弱なコードであると説明してきました（これは、目に見えないバグがあることを意味します）。
于 2013-10-09T10:01:58.433 に答える
1
「BBOM」シナリオに対処しなければならなかったのは、基本的にユーザーと一緒に要件を再検討し、恐ろしいコードから何ができるかを推測する必要がありました。すべてのBBOMと同様に、この問題は通常、メンテナンス/拡張が必要になるまで明らかになりません。（このショップではコードレビューの贅沢はありません。悲しいことに、基準は「彼らが望むことを実行するか」でした。）そして「作者」はずっと去っています。
この場合、リファクタリングも不可能でした。
于 2009-06-23T02:41:18.317 に答える
1
あなたに答えるウィキペディアの記事からの適切な引用は次のとおりです。
大きな泥だんごプロジェクトを管理しているプログラマーは、それを研究し、それが何を達成するかを理解し、これを、それを置き換えることができる適切に設計されたシステムの正式な一連の要件の緩い基礎として使用することを強くお勧めします。
于 2009-06-23T03:00:04.190 に答える
0
これは、元の質問にいくらかの光を当てるかもしれません。
http://en.wikipedia.org/wiki/Big_ball_of_mud
大きな泥だんごは、知覚可能なアーキテクチャを欠いているソフトウェアシステムです。エンジニアリングの観点からは望ましくありませんが、このようなシステムは、ビジネス上のプレッシャーと開発者の離職により、実際には一般的です。したがって、これらはデザインのアンチパターンとして宣言されています。
于 2009-06-23T02:42:06.740 に答える