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

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

В подобной ситуации возникает соблазн использовать то, что давно хотелось попробовать в реальном проекте: rust’е, js-фреймворк, clickhouse и т.д. Но чтобы выбрать правильный инструментарий, стоит взвесить все «за» и «против». Технический директор RedLab Антон Новоженин делится списком вопросов, которые помогут принять правильное решение.

Anton Novozhenin

Технический директор RedLab

На какую цель работает инструмент?

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

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

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

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

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

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

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

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

Есть ли в команде необходимые разработчики?

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

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

Позволит ли рынок труда быстро масштабировать команду? 

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

Можно проанализировать состояние рынка труда по основным показателям:

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

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

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

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

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

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

Заключение

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

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