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

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

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

Стоимость запуска проекта

Если вы фанат Microsoft или серийный убийца RoR, то это может не иметь для вас большого значения. Существует почти один известный и рекомендуемый способ начать любой проект. Но если вы живете на Арене смерти Javascript, как и мы, то это может быть головной болью каждый раз, когда вы начинаете новый проект.

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

Наш подход

Что ж, мы уже проходили через эту боль раньше, и, к сожалению, вы не сможете не пройти через нее, пока вы решили пройти через Javascript (что кажется неизбежным в наши дни). Лучшее, что вы можете сделать, это придерживаться варианта (как только вы нашли разумный вариант) и придерживаться его в течение нескольких лет (2–3 года звучит разумно).

Однако выбор стека технологий — черное искусство. Здесь нет серебряной молодки. Но мы представим наш подход к этому.

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

Выбор стека технологий

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

Этап исследования:
 На этом этапе мы попытались составить список как можно более разумных целевых популярных основных технологий. Делится на две основные категории Frontend/Backend. Под основными технологиями мы подразумеваем React, Angular, Vue.js, Meteor, Sails.js, Loopback и т. д. И в мегалисте Excel мы перечислили все ссылки на наши целевые ресурсы, которые будут использоваться для исследования. Эти ссылки были в основном мнениями экспертов, официальной документацией и онлайн-дебатами между этими технологиями, их плюсами и минусами… и т. д. Кроме того, мы прошли аналитику тенденций, включая количество зарегистрированных ошибок, звезд github и т. д. И для каждой ссылки мы указали приоритет и ожидаемое время анализа. С каждым новым ресурсом, который мы открывали, появлялись новые ссылки на другие ресурсы, а важные мы вставляли в тот же лист. Мы продолжали обновлять приоритеты ссылок по мере продвижения.

Этап прототипирования:
Это не совсем отдельный этап, мы провели несколько очень быстрых экспериментов, чтобы подтвердить результаты нашего исследования. Либо это приводит к дополнительным исследованиям, необходимым для выбора. Или отказ от варианта. При создании этих прототипов важно помнить о вашем конкретном случае использования. И постарайтесь сделать эти прототипы близкими к вашему типичному варианту использования. Например, вы обычно работаете над очень интерактивными проектами? Является ли ваша основная цель мобильным или настольным? Является ли размер бинарного файла или (пакета) инструмента большой проблемой для вашей компании или обычного целевого клиента? ….. и т.д.

Звучит круто, но….
Вы могли бы провести вечность в этих двух шагах вперед и назад, как мы сказали в начале, как ребенок в кондитерской. Итак, мы решили следующее:

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

Для любого инструмента, удовлетворяющего двум вышеуказанным условиям, существует очень высокая вероятность того, что мы не ошибемся, выбрав его. Поэтому мы решили:

  1. Тайм-бокс на весь процесс.
  2. Когда время истечет, выберите то, что мы сочли правильным, основываясь на эвристиках и экспериментах, которые мы провели до сих пор.
  3. Мы знаем, что никогда не сможем выбрать «идеальный» стек для наших случаев. Но "Хорошо" вполне достаточно.

Этот этап занял у нас примерно 1,5 месяца. Пока мы не остановились на стеке технологий. Время истекло, прежде чем мы подробно изучим все доступные варианты. Но, как мы сказали, мы считали, что достигли «достаточно хорошего». И "достаточно хорошо" достаточно хорошо!

Максимизация прибыли

Я считаю глупым и крайне непродуктивным использовать новую технологию для каждого нового проекта (или даже для каждых нескольких новых проектов). ИМХО, я считаю, что вы должны придерживаться выбранного вами стека технологий в течение нескольких лет, чтобы пожинать плоды накопленных ноу-хау и выделяться из толпы. Например, существует огромное количество поклонников Angular. То же самое для React и Vue.js. Вы можете найти их там в Интернете, ругая друг друга. Но в любом из этих технологических стеков не так много настоящих экспертов. Поскольку, чтобы освоить любой стек и быть чрезвычайно продуктивным, вам нужно потратить несколько лет на свою технологию. Чтобы расширить свои знания о его слабых сторонах и о том, как настроить его производительность. Например, просматривая статьи, я наткнулся на бесконечное количество людей, жалующихся на то, что их приложение Meteor было раздавлено первой волной реальных пользователей. Ну, они были просто в основном новичками, которые не понимали, как Meteor работает под капотом, и использовали все его изящные функции, не понимая его слабостей (от которых относительно легко защититься, если вы знаете, что ищете).

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

Мой общий совет: если новая технология явно (и все об этом говорят) в 5–10 раз лучше выбранной вами технологии. Куча. Тогда иди к этому новому парню в городе. В противном случае придерживайтесь того, что у вас есть, и продолжайте пожинать плоды. Когда мы говорим «в 10 раз лучше», это включает в себя, как будет легко найти/нанять разработчиков, которые захотят его использовать? Насколько он поддерживается на клиентских платформах (браузерах и мобильных устройствах и т. д.)? Поддерживает ли он возможности современных устройств? Будете ли вы по-прежнему конкурентоспособны на рынке (для сервисных фирм)? И, очевидно, сокрушает ли новичок его производительность или продуктивность?…..и т.д.

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

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