Или почему 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‑канале «Техдир на пальцах»: без кода, без рекламы фреймворков — только практические ошибки и выводы из них.
Автор: Techdir_hub
