Скорость команды разработки — свойство системы, а не скорость самого быстрого ковбоя на Диком Западе

Скорость команды часто пытаются измерить количеством сильных разработчиков. Но самый быстрый человек в хаотичной системе обычно не ускоряет команду. Он просто первым начинает компенсировать её проблемы. В большом проекте скорость чаще теряется не в коде, а между мыслью «надо поменять вот это» и моментом, когда изменение можно будет увидеть, обсудить, проверить и выпустить. Представьте: большое iOS приложение для широкой аудитории, несколько рынков, которые собираются из одного проекта, часто обновляющиеся данные и экраны, которые product хочет менять быстрее, чем новый релиз успевает дойти до пользователей. В такой среде архитектура нужна не для красивой схемы. Она нужна, чтобы изменения были дешёвыми. Запускать модули отдельно Одна из самых дорогих операций в большом проекте — дождаться полной сборки. Разработчик может прийти поправить один экран, изменить несколько строк и затем ждать, пока соберётся весь продукт: соседние модули, ресурсы, зависимости и части, которые не имеют отношения к задаче. А если сделать так, чтобы крупные разделы можно было запускать отдельно — только с нужной функциональностью? Это даёт простой эффект: изменение быстрее видно, его не страшно переделать. Можно изолированно проверить несколько связанных экранов, а новому разработчику не нужно сначала разобраться во всём проекте, чтобы принести пользу в одном разделе. Если результат долго ждать, люди начинают гадать, но если его можно увидеть быстро — проверяют гипотезы. Экраны отдельно, но не приложения Но отдельный запуск разделов не значит, что каждый экран становится отдельным приложением. Другая частая ловушка мобильной разработки — разложить один экран на множество формальных ролей и файлов. В итоге логика оказывается размазана так, что для изменения одной кнопки нужно пройти весь ритуал: понять, где живёт событие, кто передаёт его дальше и в каком из слоёв лежит нужное состояние. Для многих экранов достаточно пяти вещей: View — то, что видит пользователь. Model — состояние экрана: загрузка, данные, ошибка, выбранный элемент. Input — с чем экран открывается. Output — что он возвращает, когда закончил работу. Builder — место, где собираются зависимости.