Фантомный баг в расчётах: поиск в логах спасает проект

Охота за фантомом: как мы поймали баг, которого не было

Проект trend-analysis набирал обороты. Система анализирует тренды с Hacker News и выставляет им оценки влияния по шкале от 0 до 10. Казалось бы, простая задача: посчитал метрики, вывел число. Но тут всплыла странность: два анализа одного и того же тренда показывали разные score — 7.0 и 7.6. Баг или особенность? Это нужно было разобрать срочно.

Первым делом я начал копать в логах. Посмотрел на слой API — там в routes.py происходит расчёт score. Начал читать функцию вычисления и… стоп! Вижу: в коде ищет значение по ключу strength, а передаётся оно в поле impact. Классический мисматч! Вот и виновник. Исправил на корректное имя поля — это был первый коммит (b2aa094).

Но постойте, это только половина истории. Дальше зашёл в frontend-часть — компоненты formatScore и getScoreColor. Там была нормализация значений, которая превращала нормальные числа в какую-то кашу. Плюс точность вывода — показывал слишком много знаков после запятой. Переделал логику: убрал лишнюю нормализацию, установил .toFixed(1) для вывода одного знака после запятой. Это стал второй коммит (a4b1908).

Вот здесь и произошла интересная вещь. После исправлений я переходил между trend-страницей и analysis-страницей проекта и заметил, что интерфейс работает по-разному. Оказалось, что эти страницы нужно было унифицировать — одна и та же логика расчёта должна работать везде одинаково. Это был уже третий коммит, где мы привели весь scoring к единому стандарту (feat: unify trend and analysis pages layout and scoring).

Любопытный факт: когда ты работаешь с несколькими слоями приложения (API, frontend, бизнес-логика), очень легко потерять консистентность в названиях полей и форматировании данных. Такие проблемы обычно проявляются не в виде крашей, а в виде “странного поведения” — приложение работает, но не совсем как ожидается. Git-коммиты с описанными ошибками — отличный способ документировать такие находки.

По итогам расследования выяснилось: score 7.0 и 7.6 — это совершенно корректные значения для двух разных трендов, а не баг в расчёте. Система работала правильно, просто нужно было почистить код и унифицировать логику. Все три коммита теперь в main, изменения готовы к деплою.

Вывод простой: иногда самые раздражающие баги на самом деле — это следствие разрозненности кода. Дефрагментируй систему, приведи всё к одному стандарту — и половина проблем решится сама собой.

Что будет, если AWS обретёт сознание? Первым делом он удалит свою документацию 😄