Или почему shiny tech stack ≠ рабочий продукт.
В современном IT есть незаметный, но опасный тренд: влюблённость в технологии, а не в результат.
Каждую неделю выходят новые «киллеры» фреймворков, базы данных, фреймворки на фреймворки, UI-библиотеки, подходы к state management, архитектурные паттерны и всё прочее.
И команда — чаще всего молодая и горящая — тащит их в прод:
Здесь проще. С этим быстрее. У нас будет красиво, как в статье на Medium
На демо — действительно красиво. А потом приходит прод.
Когда инструмент работает не на тебя, а против
В одном проекте (B2B-платформа) было принято решение перейти на модную NoSQL БД. Синтетические бенчмарки сулили бешеную производительность, а статья “как мы ускорили всё в 20 раз” казалась аргументом для молодых разработчиков.
Спустя 3 месяца:
база не тянула растущий трафик,
появилось странное поведение при индексации,
шардирование пришлось пилить вручную,
бэкапы оказались полуручными,
а любые вопросы в гугле приводили на GitHub с unanswered issue
Всё закончилось тем, что часть системы пришлось переписать — на проверенный, пусть и скучный, стек.
Почему так происходит?
Потому что в момент выбора технологий в голову лезет не «как оно будет жить через год», а «как будет круче». И здесь важный момент: фреймворк — это не “удобная штука для разработчика”, это часть бизнес-инфраструктуры.
Когда вы внедряете что-то: с сырой документацией, без комьюнити, без инструментов отладки, без понятного опыта продакшен-эксплуатации, вы не экспериментируете — вы закладываете в проект мину замедленного действия.
Что должен учитывать человек, принимающий решение
На что действительно стоит смотреть при выборе инструмента для production:
Обкатанность. Используется ли в проде? Сколько лет? Где именно?
Экосистема. Есть ли утилиты, плагины, интеграции?
Сообщество. Есть ли люди, которым можно задать вопрос? Много ли открытых багов?
Команда. Готовы ли ваши разработчики поддерживать это без боли?
План Б. А что, если придётся отказаться? Есть ли миграционный путь?
Проверенное ≠ устаревшее
Часто слышу:
«Ну вы используете старье. Всё на Django, всё через PostgreSQL, сейчас же есть топовый ...»
Зато: развёртывается в два клика, легко поддерживается даже новым человеком, мониторится стандартными средствами, и выдерживает рост без коллапса. (Споры по поводу примера разводить не стоит)
Технологии — это не про «интересно». Это про ответственность.
Хочешь попробовать что-то новое? Прекрасно. Заводи pet-проект, играйся на хакатонах, делай эксперименты. Но в коммерческом продукте цена ошибки может быть бизнесу не по карману.
В завершение
Выбор стека — не фаза «для галочки». Это стратегическое решение. Оно должно отвечать на один вопрос: «Позволит ли это нам уверенно развиваться через 6, 12, 24 месяца?» Если да — пусть он будет хоть на Flask и jQuery. Если нет — вы просто тянете красивую бомбу с таймером.
Если вам близки такие разборы — я делюсь кейсами в Telegram‑канале «Техдир на пальцах»: без кода, без рекламы фреймворков — только практические ошибки и выводы из них.
