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

Некоторые технологические стеки стали настолько популярными, что получили собственные аббревиатуры: например, MEAN (MongoDB, Express.js, AngularJS и Node.js) или LAMP (Linux OS, Apache Web Server, MySQL и PHP). Эти стеки относятся к традиционным серверным, которые пока имеют наибольшую популярность. Вместе с этим наблюдается рост интереса к бессерверным стекам, которые, как понятно из названия, почти не требуют усилий для управления серверами. Достаточно небольшого куска кода, чтобы настроить всё, включая CI, а также предусмотреть масштабирование. Но при этом вы теряете в возможностях кастомизации. У бессерверных стеков есть и другие ограничения. Например, холодный старт виртуальных машин с нуля может занимать очень долгое время. Тем не менее бессерверные стеки сегодня активно набирают популярность, так как вполне могут покрыть 80–90% всех кейсов — ведь глубокая кастомизация нужна далеко не всегда.

Расширение техстека

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

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

Не стоит добавлять фреймворки и библиотеки по первой же просьбе заказчика. Важно предусмотреть возможные последствия, обсудить их и договориться о том, как вы будете решать возможные проблемы, чтобы не остаться в накладе. Чем больше вы связаны с заказчиком, тем меньший простор для действий у вас есть — махнуть рукой может только фрилансер. Но с другой стороны, при долгой работе вместе уровень взаимного доверия растет, и на встречах вы можете попробовать аккуратно докопаться до причины, по которой заказчик упирается в неудобный для вас инструмент. «У нас в команде есть человек, который знает только эту аналитическую платформу и всё, а обучать его возможности нет». Здесь у вас появляется большее пространство для маневра; оказывается, потребность заказчика продиктована всего одним человеком.

Если же клиентский стек распух до невероятных размеров, и потенциально это может приобрести к проблемам, стоит пристально последить за его использованием хотя бы несколько месяцев. Бывает, что за все это время в некоторые проблемные системы даже никто не заходит, хотя в начале работы заказчик стоял за них насмерть. Это повод собрать встречу, чтобы попробовать убедить заказчика отказаться от них. Проведите демо, которое наглядно показывает, насколько неиспользуемая аналитическая система тормозит скорость загрузки. Предложите перенести ее интеграцию на вторую фазу проекта.

Клиентский стек — это основа проекта, и его развитие нужно планировать заранее. Например, если у вас в стеке есть Firebase, который позволяет подключать максимум 100 пользователей, а в обозримом будущем заказчику понадобится 105, то стоит задуматься либо об альтернативном решении, либо о разделении пользователей на два проекта.

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

Выбор техстека

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

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

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

Часто бывает, что заказчик не может сформулировать, что он хочет, пока вы не посвятите его требованиям отдельную встречу. К этому можно прийти с помощью правильно поставленных вопросов с вашей стороны. И уже потом вы начинаете сопоставлять их потребности и ваши возможности. На этом этапе очень важна коммуникация именно через встречи, а не через почту — это будет гораздо эффективней. Придется быть гибким, придется потратить много сил, но отнеситесь к этим встречам как к самым важным на протяжении всего проекта. В одной компании по веб-разработке есть правило: каждый новый проект начинается с пятичасовой встречи с заказчиком. И если он на неё не готов, проекта не будет. Потому что каждый из этих пяти часов может сберечь сотню часов во время проекта.

На этом этапе можно легко подписаться под «изобретение велосипеда» в крупных масштабах — в значит, под лишние расходы для себя и заказчика. Когда у вашего будущего клиента уже отлично сложилась работа с каким-нибудь WordPress, и он просто хочет вести с его помощью блог на своем будущем портале, не стоит планировать кастомное решение на основе личной неприязни к «этому старью». Если, конечно, вы не видите больших технических проблем с интеграцией WordPress.

Стоит учитывать при этом и скилы собственной команды. Если они хорошо работают с Webflow, а заказчику все еще нужен многострадальный WordPress, то вам потребуется больше времени, чтобы начать полноценную работу с новой платформой. Когда заказчик поймет, что при сохранении всех условий проект может задержаться на месяц-два, то, может, Webflow покажется хорошей альтернативой. Это же справедливо и для более глобальных кейсов — например, выбора между LAMP и serverless.

Договорившись о стеке, ешьте его по частям. Запланируйте этапы проекта, порядок внедрения и дедлайны. Это особенно важно, если заказчик не любит первым выходить на связь — такой недостаток общения может привести к проблемам, поэтому по регламенту взаимодействия постарайтесь предусмотреть как можно больше «на берегу». Если вы не можете закрыть какие-то вопросы своими силами, порекомендуйте найти еще одного подрядчика — скажем, на поддержку многострадального WordPress. Или выступите сами в этой роли, если позволяют ресурсы — для заказчика это будет привлекательней, чем еще одна встреча с новыми людьми.

Развитие техстека

По мере развития успешного проекта стоит задуматься о его перспективах. Веб-разработка развивается быстрыми темпами — даже тот же WordPress, не говоря уже о более новых инструментах. А может, стоит поддаться общему тренду и двигаться в сторону бессерверного стека? В любом случае, для развития придется в некоторой степени выйти из зоны комфорта. Возможно, новый путь подскажут сами заказчики, которые придут с новыми для вас техническими требованиями — способными открыть для компании большие перспективы.