Когда рисовать UML
UML — не обязательный ритуал, а инструмент для конкретных ситуаций. Рисовать диаграмму на каждый чих не нужно — это трата времени без пользы. Используй её, когда она реально решает задачу коммуникации.
Стоит рисовать, когда:
- Объясняешь архитектуру новому человеку в команде — схема быстрее, чем читать весь код;
- Обсуждаешь дизайн перед написанием кода — на доске/Miro дешевле ошибиться и переделать, чем после того, как код уже написан;
- Документируешь сложное взаимодействие между несколькими сервисами/классами, которое сложно удержать в голове;
- Готовишься к собеседованию на позицию, где ожидают умение проектировать систему.
Не стоит рисовать, когда:
- Структура простая и понятна из самого кода — диаграмма станет лишним документом, который никто не будет обновлять;
- Это разовая задача, и через неделю про неё забудут — поддерживать диаграмму в актуальном состоянии дороже, чем просто прочитать код.
Копнуть глубже
Главная опасность UML — устаревшая диаграмма. Диаграмма, нарисованная один раз и не обновляемая вместе с кодом, со временем начинает врать — показывает не то, что есть на самом деле. Это хуже, чем отсутствие диаграммы вообще, потому что вводит в заблуждение.
Практичный подход в реальных командах: UML-диаграммы чаще рисуют временно, для конкретного обсуждения (на доске, в Miro, в комментарии к Pull Request) — а не как постоянно поддерживаемую документацию. Исключение — действительно сложные, редко меняющиеся части архитектуры, где актуальная диаграмма экономит время многим людям надолго.
• почему устаревшая диаграмма хуже, чем её отсутствие (если дошёл до 2-го слоя).