Дешёвый костыль сегодня — дорогой завтра

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этом посте были ссылки, но мы их удалили по правилам Сетки