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

29 апреля 2020
Поделиться
Anton Novozhenin
Anton Novozhenin
Технический директор RedLab

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

В такой ситуации, возникает соблазн использовать что-то модное — то, что давно хотелось попробовать в реальном проекте. Запилить сервис на rust’е, использовать новый, набирающий популярность, js-фреймворк, подключить clickhouse и т.д. Думаю, у каждого инженера найдется такой wishlist.

В этом случае стоит сделать паузу, налить чашку кофе/чая/молока и взвесить все «за» и «против».
У меня есть список вопросов, которые я задаю себе в таких ситуациях — они помогают мне принять правильное решение.

alt
Антон Новоженин
Эксперт по разработке ИТ-продуктов
Забронировать звонок с экспертом

Почему именно этот инструмент

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

Я стараюсь посмотреть на ситуацию с двух сторон: со стороны своей команды (и своих интересов, в том числе) и со стороны заказчика (и текущего проекта). Если новый инструмент будет полезен и тем и другим — это хороший знак и можно переходить к следующему вопросу.

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

Насколько зрелый сам инструмент. Кто и как его разрабатывает

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

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

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

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

Кто внутри компании будет заниматься разработкой

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

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

Какова ситуация на рынке труда

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

Отвечая на этот вопрос, я стараюсь проанализировать состояние рынка труда по основным показателям:

  • стоимость специалистов;
  • баланс спроса и предложения;
  • динамика роста количества вакансий и соискателей на них.

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

Как заказчик будет поддерживать готовый продукт?

Если у заказчика есть inHouse-команда разработки, необходимо подумать от том, кто и как будет поддерживать разработанный продукт: какой стек они используют, какой у них состав команды и т.д.

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

Мы всегда ставим в приоритет долгосрочное сотрудничество, а не сиюминутную выгоду — и такой подход дает хорошие результаты.

Заключение

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

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

А вообще, лучший способ попробовать новый язык программирования или фреймворк — реализовать какой-нибудь Proof of Concept или Pet Project (как свой личный, так и в рамках компании). Здесь критерии для выбора инструментария будут менее жесткими, а цена ошибки не так высока.