Скорость команды разработки – свойство системы, а не скорость самого быстрого ковбоя на Диком Западе
<img src="https://habrastorage.org/getpro/habr/upload_files/0dc/540/c91/0dc540c915c66fb41ed2ae31770b1ff9.jpg" /><p>Скорость команды часто пытаются измерить количеством сильных разработчиков. Но самый быстрый человек в хаотичной системе обычно не ускоряет команду. Он просто первым начинает компенсировать её проблемы.</p><p>В большом проекте скорость чаще теряется не в коде, а между мыслью «надо поменять вот это» и моментом, когда изменение можно будет увидеть, обсудить, проверить и выпустить.</p><p>Представьте: большое iOS приложение для широкой аудитории, несколько рынков, которые собираются из одного проекта, часто обновляющиеся данные и экраны, которые product хочет менять быстрее, чем новый релиз успевает дойти до пользователей.</p><p>В такой среде архитектура нужна не для красивой схемы. Она нужна, чтобы изменения были дешёвыми.</p><p><strong>Запускать модули отдельно</strong></p><p>Одна из самых дорогих операций в большом проекте – дождаться полной сборки.</p><p>Разработчик может прийти поправить один экран, изменить несколько строк и затем ждать, пока соберётся весь продукт: соседние модули, ресурсы, зависимости и части, которые не имеют отношения к задаче.</p><p>А если сделать так, чтобы крупные разделы можно было запускать отдельно – только с нужной функциональностью?</p><p>Это даёт простой эффект: изменение быстрее видно, его не страшно переделать. Можно изолированно проверить несколько связанных экранов, а новому разработчику не нужно сначала разобраться во всём проекте, чтобы принести пользу в одном разделе.</p><p>Если результат долго ждать, люди начинают гадать, но если его можно увидеть быстро – проверяют гипотезы.</p><p><strong>Экраны отдельно, но не приложения</strong></p><p>Но отдельный запуск разделов не значит, что каждый экран становится отдельным приложением.</p> <a href="https://habr.com/ru/articles/1080244/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1080244#habracut">Читать далее</a>