Мы много работаем с легаси. Основной пул наших клиентов — это проекты на развитие и поддержку текущих систем. И именно здесь как нельзя лучше всплывают два вопроса: стоимость поддержки кода и скорость релизов.

Стоимость поддержки

Когда идёт разработка нового проекта — сайта, интернет-магазина, B2B-платформы или чего-то похожего — мало кто думает о том, сколько будет стоить дальнейшее развитие. Решения, которые закладываются на старте, часто не просто не адаптированы под поддержку, они прямо ей сопротивляются.

И это, наверное, нормально. Я уже писал, почему веб всё ещё делают плохо. Но ситуация кардинально меняется, когда работаешь с долгосрочным проектом. Здесь нельзя просто «подписать акты, отдать проект и пусть он живёт сам по себе». На таких проектах любой костыль будет использован против вас.

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

Архитектура и варианты решений

Я уже писал, что одна и та же задача может иметь сотни вариантов реализации. Так вот, при выборе решения лучше подумать, как оно ляжет в проект: станет чем-то обособленным или встроится в систему.

Да, работа по проектированию и архитектуре увеличивает стоимость конкретной задачи. Но зато в будущем может сберечь от рефакторинга целых блоков (а иногда и всего проекта). Оценить это сложно, но сердце подсказывает: так правильно.

Скорость релизов и TTM

И вот вторая история. Чем хуже код, тем сложнее релизы, тем дольше time to market. А бизнес это ненавидит. Он хочет: придумал задачу — передал идею — вчера уже на боевом проекте. В жизни так не работает.

Чтобы улучшить TTM, есть стандартные механики: автотесты, автоматические релизы, организованные процессы.

Увидел тут мысль котороая кратко и точно отражает суть.
Архитектура — это о стоимости изменений. Хорошая архитектура делает изменения дешёвыми. Плохая — дорогими. Если вам кажется, что хорошая архитектура стоит дорого, попробуйте плохую.

Можно очень сильно автоматизировать процесс релизов, но на это уйдут часы и деньги — не всякий бизнес на это готов. Поэтому TTM всегда компромисс: сколько времени даём на разработку, тестирование и релиз.

В идеале релизы должны быть минимальными по времени и маленькими по объёму. Их проще тестировать, проще выкатывать и безопаснее. И лучше делать их чаще, чтобы не копилась очередь и зависимости между задачами.

Вывод

Всё упирается в архитектуру и культуру команды. Можно долго спорить, что важнее — скорость или качество. Но на практике выигрывают те проекты, где удалось найти баланс и встроить его в процессы. Потому что костыль может показаться дешёвым решением сегодня, но завтра он обойдётся куда дороже.