Погружаясь в разработку, компания выбирает язык программирования, фреймворки, продумывает архитектуру. Но принятые на старте решения могут «закостенеть» настолько, что будут определять дальнейшее развитие приложения или сервиса. Порой внесение изменений требует полной переработки продукта — особенно в устоявшихся организациях. Мы в T1 Cloud предлагаем решения для бизнеса и хотим поговорить, как с этим вопросом можно работать.

Уловка-22

Начиная разработку нового продукта, компаниям часто приходится срезать углы. Они внедряют неоптимальные программные решения, добавляют костыли в код — то есть делают все, чтобы как можно быстрее построить прототип и вывести его на рынок. Иначе бизнес рискует завязнуть во внутренних процессах. Порядка 20% всех стартапов в США закрываются в течение двух лет. Еще больше не доживают до пятого года работы, а технологические проекты находятся в отдельной группе риска.

Однако, подбирая быстрые решения, компания начинает копить технологический багаж. Он преследует разработчиков уже после того, как продукт обзавелся аудиторией и завоевал нишу на рынке. Например, с такой ситуацией столкнулся один из резидентов Hacker News. Его компания уже перешла в стадию, когда не получится просто взять и перейти на новую базу данных или серверный стек.

Другой пример — фирма, которая занималась разработкой приборов в начале нулевых. В основу их продукта легла коммерческая операционная система. Спустя пятнадцать лет команда решила перейти на открытое программное обеспечение. Однако кодовая база уже была привязана к исходной ОС, и переработка заняла в разы больше времени.

Иными словами, когда компания запускает новый продукт, она сталкивается с «уловкой-22». Если разработчики планируют технологический стек с прицелом обойти все подводные камни на пути, они рискуют затянуть с запуском. В то же время стартапы, которые выходят на рынок с «голым» MVP, имеют больше шансов выжить. Однако быстрее копят тех. долг, в перспективе приводящий к проблемам.

Что может вызывать сложности

Вопросы на поздних этапах разработки продукта могут быть связаны с языком программирования. Переход на новую технологию или внедрение нестандартного фреймворка — все это требует времени и денег. Да и процесс сам по себе может занять месяц и даже год. Часто это связано с объемной кодовой базой и множеством зависимостей. В прошлом крупнейшая западная социальная сеть использовала PHP, однако позже решила перейти на язык Hack собственной разработки. Миграция заняла примерно год, но даже после этого остались вопросы в плане производительности.

Сам процесс переписывания ПО зачастую представляет собой монотонную и изматывающую работу. Автоматизированные инструменты упрощают задачу, но результаты все равно приходится проверять. Возможны ошибки при составлении функций и неэффективные конструкции, ради искоренения которых обычно и затеваются такие проекты. Так, еще в 2017 году разработчики одного инструмента для документооборота переводили его с Perl на Python. Работа продвигалась в десятки раз медленнее, когда дело касалось уникальных особенностей и отсутствующих возможностей в одном из языков. Сложности возникают даже при миграции между версиями ЯП. Так, конец поддержки Python 2.7 в 2020 году вызвал в сообществе волну недовольства. В том числе из-за того, что новая версия — 3.0 — не имела обратной совместимости.

Еще одним аспектом, который консолидируется на поздних этапах развития компании, является IT-инфраструктура. Облако — частый выбор стартапов, так как им не приходится закупать собственное железо, а свободные деньги они могут направить на развитие продукта. Виртуальная инфраструктура предлагает гибкость и возможность адаптировать объемы вычислительных ресурсов под расширяющуюся пользовательскую базу.

В то же время облачные провайдеры предлагают экосистемные продукты вроде СУБД, антивирусов и даже средств для разработки. Однако миграция между облаками различных провайдеров (или из on premise) на поздних этапах может быть проблематичной. В любом случае специалисты cloud-провайдеров готовы проконсультировать и предложить оптимальные варианты миграции. Хотя сроки будут зависеть от масштабов инфраструктуры — например, у одной из крупнейших видеостриминговых платформ переход в облако занял порядка семи лет.

Что с этим можно сделать

Решения, принятые на первых этапах развития компании, нелегко исправить, но с ними можно работать. Пользователи Hacker News отмечают, что хорошей практикой является прототипирование. Быстрые тесты различных архитектур и компонентов позволят лучше оценить возможности масштабирования будущего продукта — особенно если сразу учитывать подводные камни в проектной документации.

Резиденты Hacker News также рекомендуют использовать практику записи архитектурных решений (ADR). В этом случае составляется документ, где фиксируются функциональные характеристики ПО, зависимости между компонентами, используемые технологии и фреймворки, интерфейсы и API. Подход позволяет сфокусироваться на том, что именно будет делать команда разработки, причины, преимущества и недостатки принимаемых решений. Таким образом, внутри компании формируется некое подобие RFC, которое помогает следить за всеми изменениями в продукте.

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

Что касается инфраструктуры, то здесь стоит обратить внимание на open source приложения. Их гораздо проще переносить между облаками провайдеров, а при желании — развернуть на собственном железе. Контейнеризация и Kubernetes также позволяют управлять инфраструктурой в облаке и переносить её к другим провайдерам в стандартизированной манере.

Дополнительное чтение по теме в нашем блоге:

• Начать путь в разработке — что почитать «молодому» программисту

• Из энтерпрайза в стартап и обратно: история одного продакт-менеджера

• Безопасная разработка — на что обратить внимание при работе с open source