Привет, Хабр!

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

Сегодня я предлагаю обсудить более общий вопрос — выбор технологии для проекта в целом. Наверняка вам приходилось не раз отстаивать свое мнение в подобных спорах. Это как выбирать пиццу для большой компании, где у каждого свой вкус. Кому‑то нужна классика, кому‑то экзотика, а кто‑то без острого перца жить не может. Так как же убедить команду, что ваша технология — самая подходящая и сделать это без лишних споров и обид? Ох… Это сложно. Но не невозможно. Итак, давайте для начала определимся, есть ли у вас разрешение на ношение огнестрельного оружия? (От этого будет очень сильно зависеть аргументация.) Ну а если без шуток, для себя я выделил три этапа внедрения новой технологии.

Этап первый: А оно нам надо?

Прежде чем убеждать команду, предлагаю сделать глубокий вдох и задать себе простой вопрос: а надо ли использовать эту технологию вообще? Возможно, ваш внутренний техногик кричит: «Да! Это же круто! Это же инновации!». Но давайте мыслить как взрослые, ответственные разработчики (ну мы хотя бы постараемся). У нас должны быть четкие критерии, которым эта технология должна удовлетворять.

И тут важно помнить: критерии эти не высечены в камне. Они могут меняться в зависимости от проекта, сроков, уровня команды, компании и т. д. Хорошее решение — это решение, которое оптимальным образом удовлетворяет текущие потребности.

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

Этап второй: Технологический чек-лист

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

1. Поддержка и популярность. Технология должна быть живой, дышащей, с активным сообществом. То есть поддерживаемой и широко известной. Иначе вы рискуете попасть в ловушку bus‑фактора. Если вся разработка завязана на паре человек, которые «шарят», то любая непредвиденная ситуация с этими людьми может превратиться в катастрофу для проекта.

   Представьте, что вы выбрали экзотический язык программирования с маленьким сообществом. Нашли баг? Готовьтесь разбираться с ним сами, Stack Overflow вам не поможет. Ну а если вы вообще хотите убедить команду использовать вашу собственную разработку, то горите в …Простите, вспылил. Просто не делайте так, пожалуйста. Да, вы свою ценность для проекта, конечно, увеличите. Но и рисков туда добавите просто нереальное количество. Разумеется, тут бывают исключения, куда же без них‑то.

2. Понятность для команды. Если технология понятна только вам и паре сеньоров, а остальные смотрят на все это как на филькину грамоту, то задумайтесь. Внедрять то, что никто не понимает, — рецепт головной боли и долгостроя. Например, вы хотите использовать Haskell для написания бэкенда веб‑приложения, но ваша команда привыкла к императивным языкам. Результат? Проект затянется, а код будет пестреть ошибками.

3. Новизна в меру. Небольшое количество новых технологий — это хорошо, это стимулирует развитие команды. Но избыток новизны приводит к рискам и неопределенности. Обычно рекомендуется использовать не больше 30% нового. И то 30 — это самая верхняя планка для крутых ребят, которые понимают все, просто посмотрев на название.

   Я предпочитаю придерживаться 10–20% новизны. То есть на 10 технологий должно приходиться 1–2 новые, с которыми раньше не работали. Это грубо, конечно. Технология технологии рознь. И, к слову, если вы берётесь за проект, где вам придётся осваивать новый язык, фреймворк и базу данных, будьте готовы к тому, что сроки придётся сдвинуть.

4. Актуальность. Да, я понимаю, что вы привыкли к своей любимой технологии и она никогда не подводила. В целом землю плугом, прицепленным к коню, тоже очень долго пахали. Но устаревшая технология не дает вам расти, не повышает вашу ценность на рынке (хотя, да, бывают исключения) и не двигает вас вперед. Иногда проще переписать проект на новой технологии, чем поддерживать жизнь в legacy‑коде.

   Конечно, если вы разрабатываете программу для старого оборудования, которое работает только с устаревшими библиотеками, выбора у вас нет. А если вам повезет наткнуться там на заковыристый баг, то чинить его вы будете, скорее всего, сами и никто вам не поможет. Хотя если вы некромант…

Этап третий: Время убеждать

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

Вместо постскриптума

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

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

Что ж, спасибо за внимание!

Желаю вам интересных проектов и успешной разработки!