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

Как скука разработчиков убивает проекты

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

Оцениваем свои силы правильно

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

Выбираем инструменты правильно

Дак как же выбирать инструменты для решения задач? 

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

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

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

- Хороший принцип при выборе: хорошо проверенный, надежный и поддерживаемый инструмент, лучше нового, стильного, молодёжного, но не обкатанного.

А как внедрить новое?

Может возникнуть ощущение, что так ты никогда ничего нового не добавишь в свой стек. Это не так. Просто все нужно делать правильно. Я вижу два варианта:

- обкатываем на каком-то внутреннем или вообще учебном проекте. После чего, через небольшие или не сильно критичные куски/проекты добавляем себе в копилку новый инструмент.

- имеем план Б на экстренный переход к проверенному инструменту и готовность всех участников эксперимента к такому исходу (потому что при любых раскладах тут возникают переработки).

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