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

Если будущее приложение представляет из себя CLI-утилиту или является частью микросервисной архитектуры как отдельный микросервис, то разумно ограничить выбор достаточного инструмента для разработки языком программирования (vanilla development) или микрофреймворком.

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

Но если ваше приложение может ограничиться монолитной архитектурой, что на самом деле почти всегда так, то лучшим выбором был бы фреймворк с «батарейками в комплекте» или коробочное решение (CMS и конструкторы). Это позволит сократить время вывода продукта на рынок (Time to Market) и сэкономить на оплате труда разработчиков, которые должны быть, конечно, все еще достаточно квалифицированными — экономия происходит не столько за счет найма программистов по более низкой ставке, сколько за счет сокращения времени, которое требуется на разработку.

Фреймворки выбирают для разработки (1) либо небольших приложений (например, мини-CRM), где избыточный функционал коробочных решений (CMS и off-line конструкторы) для разрабатываемого приложения накладывает дополнительные издержки на кастомизацию и осложняет его долгосрочную поддержку, поскольку разработчик должен достаточно хорошо разбираться в выбранном коробочном решении из-за неизбежных сайд-эффектов при кастомизации, (2) либо для высоконагруженных приложений, где в сравнении с коробочными решениями, кроме кастомизации, узким местом начинает выступать база данных коробочного решения, спроектированная для покрытия широко круга задач предоставляющегося «из коробки» функционала.

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

В указанных выше случаях выбор коробочного решения означает необходимость для заказчика найти разработчика для конкретного решения, например, профессионального Битрикс-разработчика или Magento-разработчика. Таким образом, стоимость разработки увеличивается за счет потенциально более сложного поиска квалифицированного специалиста и проблемами с кастомизацией в процессе разработки.

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

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

Рассмотренные случаи использования для разработки фреймворков и CMS могут быть расширены за счет встречающихся «гибридных» вариантов, где приложение в процессе развития столкнулось с ограничениями «коробки», но разработка с чистого листа неоправданна с точки зрения потенциальных финансовых рисков и/или рисков сокращения компанией своей рыночной доли в случае допущения серьезных ошибок в изменении цифровой инфраструктуры. Тогда может быть принято решение о поэтапном вынесении части критически значимых элементов приложения в отдельные сервисы, разработанные, например, с учетом возросших нагрузок. В случае, например, с Битрикс некоторые элементы разработанного на его основе веб-приложения могут быть переписаны с использованием фреймворка Laravel.

Мы рассмотрели «общий случай» в выборе фреймворка или CMS, на практике всегда есть некоторый «байес», влияющий на принятие решения, например, если у компании есть собственный штат разработчиков, занимающихся разработкой продукта, то для нее может быть выгоднее сложная кастомизация приложения, уже разработанного на основе хорошо знакомой для разработчиков CMS, чем, к примеру, попытаться преодолеть ограничения «коробки» с помощью внедрение в разработку фреймворка. При этом, несомненно, переход в рамках текущей компании и проекта к разработке на фреймворке для самих разработчиков будет представлять профессиональный интерес. В этом случае многое зависит от технического лидера команды разработки или старшего разработчика, де-факто выполняющего его роль, который может обосновать необходимость перехода к фреймворку и взять на себя профессиональную ответственность за результат.

Дополнительно оговоримся, что речь идет о разработке нового веб-приложения в соответствии с документацией вендора, приложения разработанные на основе CMS, где разработка велась без использования методов API CMS и с нарушением установленных вендором правил кастомизации, фактически лишаются преимуществ перед фреймворками, для новых разработчиков существенно возрастает время поддержки и развития таких приложений, а стоимость рефакторинга может быть сопоставима с разработкой нового проекта.

Для разработки веб-приложений на основе конструкторов необходимо разделять подходы с использованием off-line и on-line конструкторов. В первом случае речь, как правило, идет о конструкторах, функционирующих на базе CMS (например, конструктор веб-сайтов Elementor для WordPress), но не обязательно, распространены также конструкторы, генерирующие набор статичных HTML-файлов, которые пользователь конструктора (разработчик) может выгрузить на собственный сервер и сделать доступным по принадлежащему ему доменному имени.

Для понимания сложностей, возникающих у разработчика, работающего с кастомизацией приложения, созданного с помощью off-line конструктора, представим на секунду, что мы выбрали некоторый (1) бэкенд фреймворк, на его основе (2) разработали CMS и на основе этой CMS (3) разработали конструктор веб-сайтов. В этом случае другой разработчик, получивший задачу добавить новый или изменить существующий функционал на сайте, разработанном с помощью нашего конструктора, должен был бы изучить три слоя «абстракции» или три уровня управления данными, что существенно увеличивает трудоемкость, время и стоимость разработки. Использование off-line конструкторов является ошибкой, если в будущем предполагается кастомизация разработанного на его основе веб-приложения.

В случае on-line конструкторов, как правило, пользователь конструктора не имеет доступа к исходному коду бэкенда (backend) веб-приложения, что существенно ограничивает его возможности в случае, если какие-то элементы, свойства, возможности конструктора не удовлетворяют потребности пользователя – все это закладывает слишком низкий потенциал для развития разработанного веб-приложения и влечет дополнительные издержки и риски при смене платформы (будь то фреймворк, CMS или off-line конструктор). On-line конструкторы в основном подходят для небольших информационных сайтов (лендингов).

Что касается фронтенда (frontend) (внешнего вида, интерфейса) для вашего приложения, то во всех случаях, кроме некоторых конструкторов (и, конечно, консольных приложений, где, однако, может применяться псевдографика), вы можете ограничиться использованием в худшем случае рендерингом HTML силами языка бэкенда, на котором разработано приложение (это плохая практика смешивания логики и представления), использовать подходящий шаблонизатор, совсем не использовать JavaScript или использовать vanilla JavaScript, библиотеки jQuery, React, HTMX и др. Для разработки полноценных одностраничных приложений (Single Page Application) на стороне бэкенда подойдут как vanilla languages, фреймворки, так и headless CMS (например, Headless WordPress).

Однако, если большая часть задач на фронтенде технически может выполняться backend или fullstack разработчиками, то разработка некоторых достаточно сложных SPA приложений требует привлечение к разработке frontend разработчиков – это увеличивает общую стоимость разработки, поэтому необходимо определиться с формой реализации фронтенда на этапе проектирования веб-приложения.

Отдельно необходимо рассмотреть вопрос HTML-верстки, не только backend, fullstack, но и frontend разработчики не всегда обладают навыком быстрой и качественной верстки, это может привести к необходимости дополнительно привлечь к работе над проектом профессионального HTML-верстальщика, если одно из технических требований в разработке приложения — Pixel Perfect верстка, либо закладывать в стоимость и сроки найма поиск разработчиков, владеющих данным навыком.

Нередко встречается потребность в проверке некоторой маркетинговой гипотезы или в выводе на рынок приложения для стартапа – это называется «проверка концепции» (Proof of Concept) и в этом случае разрабатывается «минимально жизнеспособный продукт» (Minimum Viable Product).

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

Что касается использования AI (artificial intelligence) (в данном контексте правильнее было бы говорить large language model), то на данный момент он выступает в роли помощника для опытного разработчика. В отличие от конструкторов, результат работы LLM не детерминирован и в каком-то смысле превращает разработку в брутфорсинг задачи (перебор вариантов).

Чем яснее конечный результат для разработчика, который он должен достичь и чем больше объем кода, который он должен проанализировать и/или написать для его достижения, тем ниже эффективность и целесообразность использования LLM для закрытия задачи. Однако LLM может быть эффективна для выполнения небольших задач, в том числе повторяющихся (набор) небольших задач связанных с программным кодом. До некоторой степени это делает возможным и разработку приложения с помощью LLM — двигаясь итеративно, небольшими шагами, но требует от разработчика опыта в профессиональной разработке программного обеспечения, чтобы ясно видеть направление движения и умело управлять LLM. Еще один эффективный способ применения LLM в разработке – продвинутый поисковик.

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

Для младших разработчиков использование в разработке LLM на постоянной основе может положительно сказываться на их кругозоре и насмотренности за счет относительно большего количества закрываемых задач за единицу времени, но затормозит развитие системности мышления, а значит и инженерных навыков, что, правда, может быть до какой-то степени компенсировано добровольным самоограничением в использовании LLM (за исключением варианта использования как продвинутого поисковика) при изучении программирования, самостоятельным изучением логики, точных и естественных наук или в рамках средне-специального или высшего учебного заведения.