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