Выбор следующего технологического стека
«Эй, давайте воспользуемся Framework X, выпущенным всего несколько недель назад. Я читал, что это намного быстрее, чем то, что мы используем сейчас ». - RockstarDev2015
«О, но вы видели недавние тесты производительности библиотеки Z. Это выглядело не очень хорошо». - I_Am_Ninja
Мы, вероятно, начали бы и / или участвовали бы в подобных обсуждениях, принимая решение о решениях для использования в стеке технологий нашего продукта.
Но давайте посмотрим правде в глаза: действительно ли это те вопросы, которые должны доминировать при обсуждении темы, какие технологии мы должны использовать для нашего продукта?
Конечно, это важные моменты, которые следует учитывать, но меня беспокоят вопросы такого типа, поскольку они часто задаются в отсутствие контекста, относящегося к продукту, который мы создаем.
Таким образом, прежде чем приступить к рассмотрению технических качеств предлагаемых решений, я считаю, что было бы неплохо рассмотреть пару других аспектов.
Сообщество / экосистема
Каждый популярный фреймворк окружают группы блестящих инженеров, которые составляют его сообщество, и, решив принять это конкретное решение, мы неизбежно будем много взаимодействовать с этими парнями.
Некоторые вещи, над которыми стоит задуматься:
- Есть ли взаимное уважение среди всех в этом сообществе?
- Каковы планы на фреймворк в будущем?
- Ребята, кто его использует в продакшене? Имеют ли они аналогичные технические проблемы, как и мы?
- Насколько активны все участники проекта (будь то написание руководств / плагинов / ответы на вопросы)?
- И самое главное, хотим ли мы быть частью этого сообщества?
На мой взгляд, это важные вопросы, которые стоит рассмотреть, когда дело доходит до оценки решения для использования в нашем технологическом стеке.
Но если бы я выбрал наиболее важные критерии при выборе фреймворка, то это был бы он.
Производительность разработчика
Причина номер один, по которой я предпочитаю один фреймворк другому, заключается в том, что он повышает продуктивность наших разработчиков.
Некоторые другие фреймворки могли бы быть более производительными из коробки, они прошли боевые испытания в огромных компаниях, за ними стоят одни из величайших умов, они современные и модные ...
Но если это в конечном итоге сделает нашу жизнь трудной, будь то из-за того, что команда не имеет опыта или ей трудно понять философию, лежащую в основе решения, или из-за действительно крутой кривой обучения. Все, что он делает, это приводит к ухудшению качества кода, увеличению времени выполнения работ для отправки новых функций, что приводит к несуществующей добавленной стоимости для наших пользователей.
Следовательно, единственная выгода от принятия такого решения состоит в том, что мы чувствуем себя хорошо, потому что мы используем новейшее и, очевидно, самое крутое технологическое решение.
Признайтесь, мы, вероятно, делали это на каком-то этапе нашей карьеры.
По правде говоря, на самом деле не имеет значения, используем ли мы hipster.js, какой-нибудь передовой сервис, написанный на 10 строках кода, систему постоянного хранения в веб-масштабе или что-то еще.
По моему честному мнению, наиболее важным является то, что выбранный нами стек - это тот, который дополняет коллективный опыт и знания нашей команды, что приводит к повышению продуктивности и, безусловно, к более счастливым разработчикам.
Итак, если нет синергии между выбранным нами стеком технологий и командой чрезвычайно талантливых инженеров, с которыми мы работаем, в чем смысл?
Не выбирайте решение, которое заставит вас выглядеть круто. Выберите тот, который позволит вам и вашей команде создать отличный продукт для ваших пользователей.
