19 июня 2025 года я сходил на PiterJS #79 в Санкт-Петербурге. У вечера была приятно приземлённая тема: не о том, как выпустить очередную фичу, а о том, как поддерживать то, что уже построено — мониторинг, деплой и рефакторинг.
Программа точно соответствовала этой теме. Павел Шлыков рассказывал о том, как привести в порядок старый монолит, Александр Панфилов — о FrontOps, а Игорь Антонов — о метриках производительности веб-приложений. Со всех трёх докладов я ушёл с практическими заметками.
Неожиданным оказался Q&A. Во время сессий мне удалось выиграть два приза за лучшие вопросы. Деталь небольшая, но именно она запомнилась сильнее всего: она ещё раз напомнила, за что я ценю технические митапы офлайн. Там можно не только слушать подготовленный доклад, но и сразу проверить своё понимание, пока спикер и другие участники находятся рядом.
Самой полезной темой оказалась поддержка, а не новизна
Фронтенд-мероприятия легко превращаются в парад новых фреймворков, API и абстракций. PiterJS #79 был гораздо приземлённее. Заявленная тема вечера была посвящена поддержке уже существующего ПО.
Это важно, потому что большая часть инженерной работы начинается после первого успешного релиза. Легаси-монолит сам по себе не означает плохую систему, а «модернизация» не обязана означать полное переписывание системы. Обычно практический вопрос намного уже: какое ограничение сейчас действительно мешает системе и какое изменение уменьшит эту боль, не добавив больше риска, чем уберёт?
Поэтому три доклада хорошо складывались в одну картину. Рефакторинг меняет код. FrontOps меняет то, как фронтенд собирается, упаковывается, доставляется и эксплуатируется. Работа с производительностью меняет то, как мы измеряем результат. Это разные слои одной задачи: сохранить реальную выросшую систему понятной и управляемой.
FrontOps шире, чем Dockerfile
Одна из моих заметок с митапа была про FrontOps с Docker. Здесь важно не смешивать понятия: Docker — инструмент, а не определение FrontOps.
Ответственность за фронтенд не обязательно заканчивается после успешного npm run build. В продакшене всё равно нужно думать о воспроизводимых сборках, упаковке артефактов, передаче конфигурации приложению, откатах релизов, поведении кеша и наблюдаемости ошибок. Контейнеры могут сделать часть этого процесса предсказуемее, но не заменяют сами эксплуатационные решения.
Это полезная поправка к распространённой ментальной модели: успешная сборка доказывает только то, что сборка завершилась. Она не доказывает, что приложение корректно задеплоится, правильно поведёт себя в продакшене или что его будет легко восстановить после проблемы.
Работа с производительностью начинается с определения слова «медленно»
Доклад о производительности был особенно практичным по своей постановке задачи. В анонсе прямо говорилось о факторах, влияющих на скорость загрузки, разных метриках фронтенда, способах количественно оценить «медленно» и даже о том, почему оптимизация нужна не всегда.
Последний пункт легко недооценить. Формулировка «сделать быстрее» звучит объективно, но без метрики и заметной пользователю проблемы она быстро превращается в дорогие догадки. Нормальный процесс оптимизации начинается с определения того, что именно медленно, затем это измеряется, находится узкое место, меняется одна релевантная вещь и результат измеряется снова.
Метрика сама по себе не равна пользовательскому опыту, но она даёт обсуждению общую единицу измерения. Без измерений работа над производительностью может превратиться в набор технически эффектных изменений без понятного доказательства, что они улучшили именно важную проблему.
Q&A изменил ценность митапа для меня
Записи докладов я мог посмотреть позже, а ссылки — сохранить. Гораздо сложнее воспроизвести взаимодействие вокруг доклада. Хороший вопрос заставляет сжать собственную неопределённость до конкретной формулировки, на которую другой инженер действительно может ответить.
Два приза были приятным бонусом, но полезный вывод оказался проще: если приходить на офлайн-митап готовым участвовать, он даёт намного больше, чем если воспринимать его как живой плейлист YouTube.
У сильного технического вопроса обычно есть контекст и ограничение. Вместо «какая архитектура лучшая?» полезнее спросить, как меняется компромисс, если команда не может переписать легаси-систему, если деплой обязан сохранять обратную совместимость или если метрика производительности улучшается, а заметного эффекта для пользователя нет.
Это не значит, что каждый вопрос должен быть умным или эффектным. Он должен помогать обнаруживать предположения, границы применимости или возможные сценарии отказа.
Что я бы взял с собой на следующий технический митап
- Понимать, зачем тебе конкретный доклад. До начала сессии записать одну реальную проблему или неопределённость.
- Отделять опыт спикера от своей системы. Полезный кейс — это доказательство того, что подход где-то сработал, а не универсальный рецепт.
- Спрашивать о компромиссах. «Когда вы бы не стали это использовать?» часто полезнее, чем «какой инструмент лучший?»
- Фиксировать одно действие после доклада. Заметка становится полезнее, если ведёт к тому, что нужно проверить, протестировать или дочитать после митапа.
- Не путать убедительный доклад с доказательством для продакшена. Архитектуру, деплой и производительность всё равно нужно валидировать в своей среде.
Что осталось со мной после PiterJS
Я не хочу преувеличивать влияние одного митапа. Я не вышел с PiterJS с универсальным рецептом архитектуры, а хороший доклад не заменяет документацию, профилирование, тесты и данные из продакшена.
Зато я унес более конкретные вещи: полезные заметки о модернизации легаси-монолита, FrontOps с Docker и измерении веб-производительности; два приза за Q&A; и ещё одно напоминание о том, что на локальные встречи разработчиков действительно стоит приходить.
Запись может сохранить сам доклад. Гораздо сложнее сохранить разговор вокруг него.