Alex.Popov
Member
Когда я в первый раз запускал свой проект, я потратил почти две недели на выбор стека. Я сравнивал фреймворки, читал сравнительные таблицы, смотрел вакансии — и в итоге выбрал то, что было модным, а не то, что подходило мне. Ошибка обошлась дороже: половина времени ушла на то, чтобы переписывать код, когда продукт стал расти быстрее, чем я предполагал. С тех пор я отношусь к выбору стека как к бизнес-решению, а не как к техническому хобби.
Нажать чтобы Перейти на сайт
Первое, что я советую, — начинать с задачи, а не с технологии. Сформулируйте, что именно должен делать продукт в первые полгода: какие сценарии работают, какие данные хранятся, сколько пользователей ожидается, кто будет этим пользоваться. Мой рабочий список вопросов довольно короткий: какая у продукта главная функция, какая нагрузка в пиковые часы, какие интеграции нужны, кто будет поддерживать код после вас и сколько у вас на это денег. Как только ответы есть, выбор стека становится почти очевидным.
Второе — считайте стоимость владения, а не только скорость разработки. Стек, который вы знаете, почти всегда дешевле идеального стека, о котором ничего не знаете. Когда я выбирал между хорошо знакомой мне связкой и более современной, я специально заложил в смету два-три месяца на обучение и переписывание. Эта цифра отрезвила лучше любых статей: сэкономленные на старте недели превратились в месяцы в середине проекта. Сейчас я просто беру свой основной язык и добавляю к нему пару зрелых библиотек — это не так скучно, зато предсказуемо.
Третье, и это важнее всего, — берите технологии с большим сообществом и хорошей документацией. Мой критерий простой: если по вашей проблеме есть десятки статей и ответов на Stack Overflow и есть хотя бы пара активных контрибьюторов в нужной библиотеке, вы справитесь. Я специально избегал нишевых решений, потому что они выглядели интересно, но когда вставал вопрос поддержки, оказывалось, что кроме вас там никого нет. Ниша окупается редко, а вот зависимость от одного уставшего разработчика — вполне реальный риск.
Четвёртое — не забудьте про эксплуатацию. Выбирайте стек, который легко деплоить, мониторить и масштабировать. Мне помогло правило: если для первого релиза нужна отдельная команда инфраструктуры, значит, стек слишком сложный для текущей команды. Я держался Docker, простого хостинга и базы данных с управляемым бэкапом — этого хватило, чтобы запускаться дешево, не думая о распределённых системах. Когда появились настоящие пользователи и реальные деньги, мы уже понимали, за что платим.
Узнать подробнее →
Пятое — оставляйте себе пространство для выхода. Хороший стек не привязывает вас намертво. Смотрите на открытые форматы, стандартные API, возможность вынести отдельные части в отдельные сервисы позже. Я не строил монолит «на века», но я следил за тем, чтобы база данных, авторизация и интеграции были отделены от основной логики. Благодаря этому, когда один из моих клиентов попросил переезд, мы не начинали проект заново — мы меняли шины по дороге.
И последнее, шестое — не принимайте решение в одиночку. Поговорите с теми, кто уже запускал похожие продукты, с разработчиками из вашей будущей команды, даже если их ещё нет. Я получил больше полезных советов за три недели разговоров, чем за месяц чтения профильных статей. И ещё: запишите решение и его причины в документ, который переживёт ваш энтузиазм. Через полгода вы забудете, почему выбрали именно это, и повторите ошибки.
Если вы уже делаете выбор — расскажите, каким критерием пользуетесь вы и на чём останавливались? А может, у вас есть стек, который вы бы ни за что не повторили, и готовы поделиться, чем он оказался неудобен?
По теме советую почитать: Как выбрать стек технологий для стартапа: опыт реальных проектов
Нажать чтобы Перейти на сайтПервое, что я советую, — начинать с задачи, а не с технологии. Сформулируйте, что именно должен делать продукт в первые полгода: какие сценарии работают, какие данные хранятся, сколько пользователей ожидается, кто будет этим пользоваться. Мой рабочий список вопросов довольно короткий: какая у продукта главная функция, какая нагрузка в пиковые часы, какие интеграции нужны, кто будет поддерживать код после вас и сколько у вас на это денег. Как только ответы есть, выбор стека становится почти очевидным.
Второе — считайте стоимость владения, а не только скорость разработки. Стек, который вы знаете, почти всегда дешевле идеального стека, о котором ничего не знаете. Когда я выбирал между хорошо знакомой мне связкой и более современной, я специально заложил в смету два-три месяца на обучение и переписывание. Эта цифра отрезвила лучше любых статей: сэкономленные на старте недели превратились в месяцы в середине проекта. Сейчас я просто беру свой основной язык и добавляю к нему пару зрелых библиотек — это не так скучно, зато предсказуемо.
Третье, и это важнее всего, — берите технологии с большим сообществом и хорошей документацией. Мой критерий простой: если по вашей проблеме есть десятки статей и ответов на Stack Overflow и есть хотя бы пара активных контрибьюторов в нужной библиотеке, вы справитесь. Я специально избегал нишевых решений, потому что они выглядели интересно, но когда вставал вопрос поддержки, оказывалось, что кроме вас там никого нет. Ниша окупается редко, а вот зависимость от одного уставшего разработчика — вполне реальный риск.
Четвёртое — не забудьте про эксплуатацию. Выбирайте стек, который легко деплоить, мониторить и масштабировать. Мне помогло правило: если для первого релиза нужна отдельная команда инфраструктуры, значит, стек слишком сложный для текущей команды. Я держался Docker, простого хостинга и базы данных с управляемым бэкапом — этого хватило, чтобы запускаться дешево, не думая о распределённых системах. Когда появились настоящие пользователи и реальные деньги, мы уже понимали, за что платим.
Узнать подробнее →Пятое — оставляйте себе пространство для выхода. Хороший стек не привязывает вас намертво. Смотрите на открытые форматы, стандартные API, возможность вынести отдельные части в отдельные сервисы позже. Я не строил монолит «на века», но я следил за тем, чтобы база данных, авторизация и интеграции были отделены от основной логики. Благодаря этому, когда один из моих клиентов попросил переезд, мы не начинали проект заново — мы меняли шины по дороге.
И последнее, шестое — не принимайте решение в одиночку. Поговорите с теми, кто уже запускал похожие продукты, с разработчиками из вашей будущей команды, даже если их ещё нет. Я получил больше полезных советов за три недели разговоров, чем за месяц чтения профильных статей. И ещё: запишите решение и его причины в документ, который переживёт ваш энтузиазм. Через полгода вы забудете, почему выбрали именно это, и повторите ошибки.
Если вы уже делаете выбор — расскажите, каким критерием пользуетесь вы и на чём останавливались? А может, у вас есть стек, который вы бы ни за что не повторили, и готовы поделиться, чем он оказался неудобен?
По теме советую почитать: Как выбрать стек технологий для стартапа: опыт реальных проектов