Давай сделаем потоки разработки.

Давайте сделаем потоки разработки: от идеи к системе сбора трендов

Проект bot-social-publisher рос, и вот встала новая задача: нужно организовать рабочие процессы так, чтобы каждый проект был отдельным потоком, а заметки собирались по этим потокам. Звучит просто, но это требовало архитектурного решения. Я полез в документацию на сайте (https://borisovai.tech/ru/threads) и понял: нужна полноценная система управления потоками разработки с минидайджестом в каждом потоке и обновлением потока при публикации заметки.

Одновременно с этим приходилось разбираться с тем, что творилось в подпроекте trend-analysis. Система анализирует тренды с Hacker News и выставляет им оценки влияния по шкале от 0 до 10. Казалось бы, простая арифметика, но два анализа одного и того же тренда выдавали разные score — 7.0 и 7.6. Вот это нужно было развязать срочно.

Первым делом я погрузился в исходный код. В api/routes.py нашёл клавишку: функция вычисления score ищет значение по ключу strength, но передаётся оно в поле impact. Классический мисматч между backend и data layer. Исправил на корректное имя поля — это был коммит номер один. Но это оказалось только половиной истории.

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

Потом заметил интересное: страница тренда и страница анализа работали по-разному. Одна и та же логика расчёта должна была работать везде одинаково. Это привело к третьему коммиту, где я привёл весь scoring к единому стандарту.

Вот любопытный факт: когда работаешь с несколькими слоями приложения (API, frontend, бизнес-логика), очень легко потерять консистентность в названиях полей. Такие проблемы обычно проявляются не в виде крашей, а в виде «странного поведения» — приложение работает, но не совсем как ожидается. И выяснилось, что score 7.0 и 7.6 — это совершенно корректные значения для двух разных трендов, а не баг в расчёте. Система работала правильно, просто нужно было почистить код.

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

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