digital-garden/dev/architecture/Большой комок грязи.md
Struchkov Mark d0a4acf39c
All checks were successful
continuous-integration/drone/push Build is passing
Обновление
2024-11-27 22:08:08 +03:00

4.6 KiB
Raw Blame History

aliases tags date
Big ball of mud
maturity/🌱
2024-04-04

Большой комок грязи (Big Ball of Mud) — это термин, описывающий программную систему с нераспознаваемой архитектурой. Такие системы не имеют чёткой структуры, их сложно поддерживать и развивать.

Ключевым последствием появления большой системы с неясной архитектурой является значительное замедление разработки. Это связано с тем, что:

  • Сложность понимания кода: Новые разработчики вынуждены тратить много времени на разбор устаревших и запутанных участков.
  • Повышенная вероятность ошибок: Внесение изменений в одну часть системы часто непредсказуемо влияет на другие.
  • Снижение гибкости: Система становится менее адаптируемой к новым требованиям бизнеса.

В результате работа над новыми функциями или изменениями превращается в долгий и трудозатратный процесс.

Одним из ярких примеров большого комка грязи является Распределенный монолит. Это система, которая внешне представлена как набор микросервисов, но на практике они сильно связаны между собой. Такая архитектура унаследовала все проблемы монолитных систем, добавив к ним сложности, связанные с распределёнными взаимодействиями.

Почему возникают большие комки грязи?

  • Давление сроков: Когда бизнес требует быстрых результатов, разработчики часто жертвуют качеством архитектуры ради скорости.
  • Отсутствие единого видения: Если в команде нет согласованного подхода к архитектурным решениям, код становится хаотичным.
  • Текучка кадров: Новые разработчики могут не понимать оригинального замысла системы и добавлять решения, противоречащие существующей структуре.
  • Рост системы: По мере увеличения объёма кода его поддержка становится всё сложнее, особенно если архитектура изначально была слабой.

Как избежать появления большого комка грязи?

  • Создавать архитектурные стандарты: Документировать основные принципы построения системы и регулярно их пересматривать.
  • ../efficiency/Рефакторинг кода на ранних этапах: Регулярно пересматривать код и устранять хаотичные или устаревшие участки.
  • Обучение команды: Убедиться, что все разработчики понимают выбранный подход к проектированию.
  • Разумное планирование сроков: Учитывать время, необходимое для создания качественной архитектуры, вместо того чтобы ориентироваться только на скорость.

Мета информация

Область:: ../../meta/zero/00 Архитектура ПО Родитель:: Архитектурная концепция Источник:: Автор:: Создана:: 2024-04-04

Дополнительные материалы

Дочерние заметки