Архитектура — не власть архитектора над кодом
Архитектура нужна, чтобы команда могла менять систему, понимая последствия своих решений. Но есть опасный сценарий: чем опытнее архитектор, тем больше решений начинают проходить лично через него. Так техническая экспертиза постепенно превращается в систему согласований.
Хорошее архитектурное решение можно передать
Для этого недостаточно диаграммы. Команда должна понимать, какие свойства системы мы защищаем, где находятся границы, какие ограничения принципиальны, какие решения команда может принимать самостоятельно, а какие действительно требуют общего обсуждения.
Тогда архитектура становится не набором личных предпочтений автора, а понятной основой для следующих решений.
Проверять решения важнее, чем делать всё самому
Руководитель может глубоко разбираться в системе и отвечать за техническое качество, не превращаясь в дополнительного разработчика. Для этого существуют design review, code review, понятные принципы архитектуры, технические лидеры, автоматические проверки и критерии качества.
Я сознательно отделяю техническую ответственность от необходимости лично реализовать решение. Иначе руководитель легко становится одновременно самым дорогим разработчиком и узким местом для всей команды.
Технический долг начинается не только в коде
Иногда код просто плохо написан. Но часто дело не в конкретном коде и не в конкретном разработчике, а в том, как устроена работа: сроки систематически побеждают качество, непонятно, кто отвечает за технические решения, никто не имеет полномочий остановить накопление технического долга, поощряется выпуск новых функций, а за состояние продукта никто явно не отвечает.
В таком случае рефакторинг лечит следствие. Если не изменить причину, технический долг появится снова.
Что я обычно проверяю
- Какие решения требуют личного одобрения архитектора или руководителя.
- Понимает ли команда архитектурные ограничения или только выполняет инструкции.
- Есть ли у технических лидеров настоящие области ответственности.
- Какие требования к системе проверяются на ревью и автоматически.
- Какие управленческие или процессные решения снова создают технический долг.