Идеи, руководства и новости от нашей команды.
Отслеживание ошибок в небольшом веб-приложении сводится к четырём вещам: ловить то, что ломается, группировать повторы, читать стек в своём коде и сохранять минуту перед падением. Как каждая из них работает в браузере, что можно выбросить и когда нужен полноценный инструмент мониторинга.
Как работает воспроизведение сессии, что оно записывает и почему вместе с логами консоли и сети оно превращает размытые баг-репорты в такие, по которым можно найти причину.
Чем баг-репорт, который исправят, отличается от того, который закроют с пометкой «не воспроизводится»: структура, контекст и практический чек-лист.
Пользователь не пришлёт вам свою консоль. Как устроен сбор на стороне клиента — кольцевые буферы, перехват сетевых запросов, фильтры — и как получить его одним тегом script.
Как системно работать с багами, которые не удаётся воспроизвести: частые причины, контекст, который их раскрывает, и как не дать им повторяться.
«Не воспроизводится» — это не свойство бага. Это утверждение о разнице между двумя машинами. Таких различий всего около восьми, и у каждого свой узнаваемый признак.
DevTools открыт не на той машине. Как перехватить console, ошибки, fetch и XHR, чтобы браузер пользователя сам рассказал, что произошло, и в какие ловушки попадают наивные реализации, которые ломают страницу, за которой следят.
Я выпустил MCP-сервер, чтобы Claude Code сам доставал баг-репорты, логи консоли и сетевые запросы. Получился цикл отладки, в котором вы ни разу не открываете веб-интерфейс BugDump.
Каждый сигнал, который собирает виджет BugDump: зачем он нужен и какие из них на деле помогают исправлять баги.
Эта переписка знакома каждому разработчику. Пользователь пишет, что всё сломалось, вы спрашиваете, какой у него браузер, и пока он ответит, час уже потерян. Мне это надоело.