41 lines
4.6 KiB
Markdown
41 lines
4.6 KiB
Markdown
|
---
|
|||
|
|
aliases:
|
|||
|
|
- Big ball of mud
|
|||
|
|
tags:
|
|||
|
|
- maturity/🌱
|
|||
|
|
date: 2024-04-04
|
|||
|
|
---
|
|||
|
|
**Большой комок грязи** (Big Ball of Mud) — это термин, описывающий программную систему с нераспознаваемой архитектурой. Такие системы не имеют чёткой структуры, их сложно поддерживать и развивать.
|
|||
|
|
|
|||
|
|
Ключевым последствием появления большой системы с неясной архитектурой является значительное замедление разработки. Это связано с тем, что:
|
|||
|
|
- **Сложность понимания кода**: Новые разработчики вынуждены тратить много времени на разбор устаревших и запутанных участков.
|
|||
|
|
- **Повышенная вероятность ошибок**: Внесение изменений в одну часть системы часто непредсказуемо влияет на другие.
|
|||
|
|
- **Снижение гибкости**: Система становится менее адаптируемой к новым требованиям бизнеса.
|
|||
|
|
|
|||
|
|
В результате работа над новыми функциями или изменениями превращается в долгий и трудозатратный процесс.
|
|||
|
|
|
|||
|
|
Одним из ярких примеров большого комка грязи является [[Распределенный монолит|распределённый монолит]]. Это система, которая внешне представлена как набор микросервисов, но на практике они сильно связаны между собой. Такая архитектура унаследовала все проблемы монолитных систем, добавив к ним сложности, связанные с распределёнными взаимодействиями.
|
|||
|
|
|
|||
|
|
**Почему возникают большие комки грязи?**
|
|||
|
|
- **Давление сроков**: Когда бизнес требует быстрых результатов, разработчики часто жертвуют качеством архитектуры ради скорости.
|
|||
|
|
- **Отсутствие единого видения**: Если в команде нет согласованного подхода к архитектурным решениям, код становится хаотичным.
|
|||
|
|
- **Текучка кадров**: Новые разработчики могут не понимать оригинального замысла системы и добавлять решения, противоречащие существующей структуре.
|
|||
|
|
- **Рост системы**: По мере увеличения объёма кода его поддержка становится всё сложнее, особенно если архитектура изначально была слабой.
|
|||
|
|
|
|||
|
|
**Как избежать появления большого комка грязи?**
|
|||
|
|
- **Создавать архитектурные стандарты**: Документировать основные принципы построения системы и регулярно их пересматривать.
|
|||
|
|
- [[../efficiency/Рефакторинг кода|Рефакторинг]] на ранних этапах: Регулярно пересматривать код и устранять хаотичные или устаревшие участки.
|
|||
|
|
- **Обучение команды**: Убедиться, что все разработчики понимают выбранный подход к проектированию.
|
|||
|
|
- **Разумное планирование сроков**: Учитывать время, необходимое для создания качественной архитектуры, вместо того чтобы ориентироваться только на скорость.
|
|||
|
|
***
|
|||
|
|
## Мета информация
|
|||
|
|
**Область**:: [[../../meta/zero/00 Архитектура ПО|00 Архитектура ПО]]
|
|||
|
|
**Родитель**:: [[Архитектурная концепция]]
|
|||
|
|
**Источник**::
|
|||
|
|
**Автор**::
|
|||
|
|
**Создана**:: [[2024-04-04]]
|
|||
|
|
### Дополнительные материалы
|
|||
|
|
-
|
|||
|
|
### Дочерние заметки
|
|||
|
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|