Сейчас сайт можно собрать за вечер. Конструкторы закрывают верстку, облачные сервисы — инфраструктуру, а ИИ помогает писать код и тесты. Но чем проще становятся отдельные операции, тем больше требований появляется к самому продукту. Почему новые инструменты не отменили сложность разработки, а только перенесли ее на другой уровень, объясняет Борис Кузьмин, технический директор диджитал-агентства АЙNET.
Что упростилось
Если сравнить веб-разработку сегодня и двадцать лет назад, разница будет огромной. В 2006 году даже относительно простой сайт требовал заметно больше ручной работы: нужно было отдельно настраивать серверную часть, решать вопросы с развертыванием, подключать базовый функционал, следить за совместимостью. Сейчас значительную часть этих задач берут на себя готовые сервисы.
Доступны готовые компоненты и шаблоны в конструкторах, SSL и CDN подключаются практически автоматически, а деплой во многих случаях сводится к нескольким действиям. Авторизацию, платежи, формы, карты, уведомления и аналитику не разрабатывают с нуля, а подключают через готовые сервисы и API.
ИИ добавил к этому еще один слой автоматизации. Он помогает написать типовой код, подготовить тесты, найти ошибку или быстро разобраться в незнакомом фрагменте проекта. В результате конкретная техническая операция, на которую раньше уходило несколько часов, сегодня может занимать минуты.
Недавно мы переносили в веб старую десктопную систему учета заказов, которой почти десять лет. Когда-то такой проект занял бы несколько месяцев, но сейчас на саму разработку ушло около недели. Потребовался легкий фреймворк, готовые компоненты интерфейса и облачное хранилище для файлов. При этом больше времени потребовали не экраны и формы, а понимание того, как система реально используется: какие сценарии в ней за годы обросли исключениями и что из этого действительно нужно перенести.
Бизнес практически перестал заказывать те задачи, которые мы научились решать быстро. Двадцать лет назад сам факт наличия сайта уже мог быть отдельной бизнес-задачей. Сейчас сайт редко существует сам по себе — он должен быть быстрым, адаптивным, связанным с CRM и другими внутренними системами, передавать данные в аналитику, корректно работать с поисковыми системами, учитывать требования по работе с персональными данными и при этом развиваться после запуска. Инструменты упростили отдельные операции, но не весь проект.
Куда сместился фокус
Написание отдельной функции часто занимает меньше времени, чем ее интеграция в продукт, тестирование и дальнейшая поддержка. Хороший пример — интеграция с внешним API. Сам запрос может занимать несколько строк кода, но этим задача не заканчивается.
Нужно определить, что произойдет, если внешний сервис перестанет отвечать, вернет ошибочные данные или изменит формат ответа. Что будет, если один и тот же запрос отправится дважды? Как система сообщит о сбое? Можно ли повторить операцию без риска потерять или задублировать данные?
То же самое происходит с инфраструктурой. Ее проще развернуть, но требования к ней стали выше. Появились CI/CD, контейнеризация, мониторинг, логирование, автоматические проверки, требования к информационной безопасности. Все это не видно пользователю, но именно от этого зависит, насколько предсказуемо будет работать продукт.
Даже инструменты, которые должны повышать надежность, сами становятся источником риска. На одном из проектов подключение системы мониторинга привело к остановке продакшна. Средство наблюдения за системой тоже является изменением в ней, поэтому его приходится внедрять так же аккуратно, как новую функциональность: сначала на тестовом окружении, затем поэтапно.
Отдельный слой — требования к работе с данными. Например, статья 19 Федерального закона № 152-ФЗ обязывает оператора принимать правовые, организационные и технические меры для защиты персональных данных. Для цифрового продукта это означает конкретные требования к доступам, хранению информации и безопасности системы, поэтому трудозатраты постепенно смещаются с написания отдельных элементов на обеспечение работы всей системы.
Инструментов стало больше — решений тоже
Чем больше появляется инструментов, тем больше времени приходится тратить на выбор между ними. Для одной задачи могут существовать несколько фреймворков, облачных платформ, библиотек или готовых сервисов. Практически каждое решение будет технически рабочим, но последствия выбора проявятся позже: в стоимости поддержки, возможности масштабирования или скорости найма новых разработчиков.
В связи с этим опыт команды сегодня проявляется не только в том, какие технологии она умеет использовать. Не менее важно понимать, где технология вообще не нужна. Показательный пример — оркестрация контейнеров. Кластерные решения создавались для управления множеством серверов, но их нередко внедряют и там, где сервер один. В такой конфигурации оркестратор не дает преимуществ отказоустойчивости, зато добавляет собственный слой сложности и нестабильности. В похожей ситуации мы приняли решение отказаться от него в пользу более простой схемы, где каждый проект разворачивается отдельно и независимо от остальных. Обратная ситуация тоже встречается: когда у системы появляются требования к масштабированию и отказоустойчивости, переход на полноценную оркестрацию оправдан, хотя и стоит дороже. Вопрос не в том, какая технология современнее, а в том, какая соответствует реальной нагрузке и рискам.
Мы стараемся стандартизировать стек и выбирать минимально достаточное решение под задачу. Если проблему можно надежно закрыть готовым сервисом, нет смысла писать собственный аналог. Каждая дополнительная зависимость увеличивает стоимость сопровождения. Через год проект будет поддерживать уже не только человек, который принимал первоначальное решение, поэтому архитектура должна оставаться понятной для всей команды. Это одна из причин, почему опытный разработчик часто выбирает более простое решение, хотя технически способен реализовать гораздо более сложное.
Взгляд агентства
Бизнес часто спрашивает, почему разработка стоит дорого, если похожую страницу можно собрать на конструкторе. Вопрос логичный, ведь бывают задачи, для которых конструктор будет лучшим решением. Если компании нужен небольшой лендинг без сложной логики, нет смысла превращать его в полноценный кастомный проект. Стоимость начинает расти в тот момент, когда бизнесу требуется не страница, а система.
Например, сайт должен получать данные из нескольких источников, передавать лиды в CRM, учитывать разные пользовательские роли, синхронизироваться с каталогом товаров, выдерживать определенную нагрузку и корректно собирать аналитику. После запуска его необходимо обновлять и развивать, не ломая существующую функциональность.
По нашему опыту, именно вокруг этих задач сейчас и сосредоточена значительная часть работы команды. Так, при планировании проекта мы стараемся заранее учитывать три принципа:
- использовать стандартизированный стек там, где это возможно;
- не усложнять архитектуру без необходимости;
- проектировать дальнейшую эксплуатацию одновременно с разработкой.
Последний пункт особенно важен. После запуска появляются обновления, новые интеграции, изменения внешних сервисов, исправления уязвимостей и новые требования бизнеса.
ИИ — следующий виток
ИИ уже забирает заметную часть рутинной работы разработчика, например, помогает писать типовой код, генерировать тесты, проводить ревью и искать ошибки. За счет этого само производство кода становится быстрее и дешевле.
Сложность не исчезает — она смещается на следующий уровень. Все важнее правильно поставить задачу, выбрать подходящее решение и проверить результат. ИИ может сгенерировать рабочий фрагмент кода, но решение о том, нужен ли он продукту, как он вписывается в архитектуру и можно ли безопасно выпускать его в прод, по-прежнему принимает специалист. Ценность разработчика постепенно смещается от написания кода к пониманию того, какой код нужен и зачем.