O'Reilly『C#クックブック』 p.19 に出てきた設計アンチパターン「BBoM」が初知りだったのでメモ

BBoM（Big Ball of Mud / 大きな泥だんご）とは

オライリー本に出てきたのは「BBoM」という用語。
アンチパターンを 「BBoMパターン」 というそうだ。

Googleでググった感じ、2024年12月現在では、日本語では「大きな泥だんご」と訳した言葉を使用することのほうが多そう。

※「BBoM」で検索してもQiitaの脚注1～2個しか引っかからなかったが、「大きな泥だんご」で検索したらたくさんの記事がヒットした。とりわけ、観測圏内ではQiita上にはBBoMについて書かれた記事は見当たらなかった。
（ということもあり、「BBoM」という見出しでこの記事を書いています。個人技術ブログにはポツポツと扱われているサイトがありました）

本中では 「このパターンでは、プロジェクトを１つ作成し、アプリケーションのすべてのコードを同じ層に詰め込もうとします」 と説明されている。
書き捨てならともかく、そうでないのなら端的に最悪ですね！

下記、Wikipediaの説明。

大きな泥だんご (おおきなどろだんご、英: Big ball of mud) は理解可能なアーキテクチャが欠けているソフトウェアシステムのことを指す。ソフトウェア工学の視点から望ましくない状態にもかかわらず、このようなシステムは事業の圧力、開発者の刷新やコードエントロピーなどの理由によって当たり前に発生している、アンチパターンの1つである。 🔗 Wikipedia

ちなみに初出は Brian Foote、Joseph Yoderによって書かれた1997年の論文「Big Ball of Mud」で、ここから論文を読むことができます。

（見るからにつらそうな画像が生成された）

BBoMのメリット(?)

プロトタイプを素早く完成させることができる

とはいえ、個人的な経験で言えば、プロトタイプとして作成したものが思いの外反応がよく「これをそのまま育てて！」と言われることも少なくないため、後々つらい目に合うことも少なくないような気が……

BBoMのデメリット

開発が長期にわたると致命的に複雑化する
機能追加・バグの修正の積み重ねにより、さらにコードが肥大化
- 重複するコードも増える
  - コードが重複しているため、1ヵ所で修正したバグが別の場所に残っていて、同じバグを起こすことがある…
- いわゆる「スパゲッティコード」の出来上がり！
  - スパゲッティコードに機能追加・バグ修正を行う時間は、ずさんなプロトタイプにすることで稼いだ時間を簡単に上回る
  - コードを管理することができなくなる
開発者がバグを何度も修正しなければならないだけにとどまらず、QA、開発、顧客報告、ヘルプデスクサービス、ソフトウェア管理のライフサイクル全体を必要以上に上回って余計な時間がかかる

結論：メリットはメリットではありませんでした

BBoMを避けるための方法

方法

関心の分離
- 階層化のアプローチを採用することによって、関心の分離を実現することができる
結合度の低い設計
- ex. SOLID, GRASP, KISS...

受けられる恩恵

同じデータを別のプロジェクトデータアクセス層からアクセスすることになった場合でもプロジェクトを再利用できる
- 場合によっては難しいが、コードの重複を避けることと、データアクセスのロジックがある場所を把握できる

他参考