Скучный стек — это смелый выбор
Три месяца назад мне написал разработчик: «Ты до сих пор пишешь на PHP? Не жалко времени?»
Я написал ему в ответ один скриншот — revenue наших production-систем за последний квартал. Больше вопросов не было.
Скучный стек — это не про лень апгрейдиться. Это про то, что ты выбираешь инструмент под задачу, а не под резюме. В 2024 году, когда AI-инструменты снизили порог входа в любую технологию до нуля, вопрос «как выбрать технологический стек для проекта» стал сложнее — потому что переписать теперь дёшево, а последствия всё те же.
Откуда берётся давление менять стек
Давление не от клиентов. Клиентам нужна скорость, стабильность, цена. Им не важно, написан каталог на PHP 8.2 или на Go.
Давление от нас самих. От ощущения, что «правильный» разработчик должен работать на «правильном» стеке. От страха собеседования через три года: «Почему ты всё ещё на Bitrix, когда весь мир перешёл на headless?»
Я это чувствовал. Три года назад я всерьёз рассматривал переход всех новых проектов на Node.js, потому что «PHP устарел» — так говорили в Telegram-каналах, так писали на Хабре, так думали коллеги.
А потом посмотрел на цифры. На проекты, которые работают, зарабатывают деньги и не требуют ночных дежурств. Все они — на PHP. Некоторым 4 года. Один каталог — 28k SKU на Bitrix+Elasticsearch — не падал под нагрузкой ни разу за 2.5 года. Потому что стек был выбран под задачу, а не под тренд.
Что значит «скучный» в 2024
«Скучный» — не синоним «устаревший».
PHP 8.2 в 2024 — это JIT-компилятор, файберы, именованные аргументы, union types. Bitrix — инфраструктура с 20-летней историей отказоустойчивости в российском ретейле. Elasticsearch 8.x — стандарт поиска для каталогов, за которым стоит Elastic с 4000+ сотрудников. Про Elasticsearch как продуктовое решение — отдельно.
«Скучный» значит предсказуемый. Я знаю, что сломается и как починить. Следующий разработчик, который придёт в проект через год, не будет переобучаться с нуля.
Проект на хайповом стеке через год часто выглядит как: «автор ушёл, документации нет, зависимости устарели на три мажора». Проект на PHP через год — это просто проект на PHP.
Три вопроса перед тем, как рассматривать новую технологию
Я перестал смотреть на «что популярно» и начал задавать себе три вопроса. Когда не могу на них ответить — стек не меняю.
Сколько стоит «не знать» эту технологию через два года?
Не «как круто её знать» — а сколько стоит незнание. Конкретно: каких клиентов я потеряю? Какие задачи не смогу взять? Сколько в деньгах?
Для Go или Rust — ответ часто «нисколько» для моих задач. Мои клиенты — e-commerce, корпоративные порталы, тяжёлые каталоги. Им нужен стабильный Bitrix-разработчик, а не хайлоад-архитектор систем на сотни тысяч RPS.
Для TypeScript в 2021 ответ был «достаточно, чтобы учить» — потому что Next.js стал стандартом для headless-фронтенда, который я делаю. Я его выучил. Это окупилось.
Задача новая — или просто инструмент модный?
Если задача прежняя, а инструмент новый — это почти всегда риск.
Каталог интернет-магазина на 50k SKU — это не новая задача. Это задача с понятными контурами, решёнными проблемами, известными узкими местами. Переписывать её на новый фреймворк, чтобы «лучше масштабировалась» — значит создавать новые проблемы там, где старых нет.
Другой пример: автоматизация контентного пайплайна с Claude Code и MCP. Это новая задача без накопленного опыта. Там выбор нового инструмента оправдан — потому что старых устоявшихся решений нет.
Кто будет поддерживать это через год, когда хайп спадёт?
Не «кто напишет» — а «кто будет поддерживать». Это разные люди.
Написать на хайповом стеке может любой джун, насмотревшийся YouTube. Поддерживать, дебажить, масштабировать — нужен человек с production-опытом. На Bitrix таких в России тысячи. На Bun или SolidJS — я не уверен, что найду замену быстро.
Когда я отказался от $40K-контракта на переписывание Bitrix — именно этот вопрос стал решающим. Не «получится ли переписать», а «кто будет поддерживать, когда проект вырастет». Ответ был неудобным. Подробнее об этом решении — в отдельной статье.
Когда я всё же поменял стек — и пожалел
Честность важна, поэтому вот история не про успех.
Два года назад для одного внутреннего инструмента студии я выбрал Python-backend вместо PHP. Причина: мне хотелось попробовать FastAPI, я видел его в нескольких крутых проектах. Задача — стандартный CRUD с несложной логикой, где PHP справился бы за день.
Итог: FastAPI написал за три дня. Потом полгода поддерживал окружение для деплоя, разбирался с зависимостями, объяснял коллеге структуру. В итоге переписал на PHP за два дня. Всё.
Это не значит, что FastAPI плохой. Это значит, что задача не требовала нового инструмента — я его принёс ради интереса. Цена интереса — время, которое мог потратить на что-то важное.
Когда консерватизм — ошибка
Я не защищаю стагнацию. Есть случаи, когда «скучный» выбор — это настоящая ошибка.
- Команда не знает выбранный стек и нет времени на обучение — тогда чужой «скучный» для вас технически незнакомый.
- Задача принципиально новая без аналогов в зрелых решениях — там экспериментировать оправдано.
- Технология теряет поддержку вендора — это не хайп, это реальный риск (Python 2 был реальным примером).
- Конкуренты на рынке труда поголовно требуют другой стек — если это ваш рынок, считайте карьерный риск честно.
Разница между консерватизмом и застреванием проста: осознан ли выбор. Если я могу объяснить, почему PHP лучше для этой задачи — это консерватизм. Если просто страшно учить новое — другая история.
Итог
Выбор «скучного» стека в 2024 требует больше смелости, чем прыжок на хайп. Потому что хайп — это социальное одобрение. Его выбор не требует объяснений. А выбор PHP объяснять приходится — клиентам, коллегам, себе в момент сомнений.
Три вопроса, которые помогают:
- Сколько стоит не знать эту технологию через два года?
- Задача новая, или только инструмент модный?
- Кто поддержит это через год?
Если ответы в пользу нового — меняю. Нет — остаюсь. Без извинений.
*Если стоишь перед похожим выбором или звучит «давайте перепишем» — пишите в DM. Обсудим до того, как подпишете контракт.*