Охота за вторым вызовом: как найти забытого баг-ассистента

Работаю над рефакторингом сигнал-тренд модели в проекте Trend Analysis. Задача вроде стандартная: перепроверить все места, где вызываются критические функции обновления трендов. Но тут я натыкаюсь на классическую историю про код, который живёт своей жизнью.

В analysis_store.py на строке 736 я нахожу ещё один вызов update_trend_scores. Казалось бы, мелочь. Но вот в чём подвох: в первом проходе я уже обновил несколько вызовов функции, отрефакторил логику. И вот этот, затерянный где-то в середине файла, остался в старом формате. Такие ситуации опасны—когда часть кода живёт по одним правилам, а часть по другим. Это источник багов, которые проявляются в production и заставляют спешить с патчами.

Приходится запускать верификацию. Делаю полный проход по проекту, ищу все вызовы update_trend_scores и score_trend. Python это облегчает—можно просто grep по всему src/. Находится порядка 10-15 вызовов, разбросанных по разным модулям. Часть в обработке данных, часть в API-слое, часть в фоновых задачах.

Потом поднимаю lint. Не мой рефакторинг создал проблемы—в db/ уже накопились давние стиль-нарушения. Но я внимателен к своему коду: проверяю только src/ и api/. Zero issues. Это базовое правило: перед push-ом убедиться, что твои изменения не усугубляют ситуацию.

Здесь раскрывается философия рефакторинга на Python. Язык динамический, типы не проверяются статически—полагаемся на внимательность и тесты. Потому система версионирования, логирование и code review становятся критичными. Каждый поменял сигнатуру функции? Значит, нужно проверить все 15 вызовов. Это не оптимально, но честно.

Финальный step—убеждаюсь, что все файлы, которые импортируют обновлённые модули, уже в git. Локально существующие файлы не считаются. CI работает с чистым checkout, и если забыть добавить важный модуль—Pipeline упадёт.

Почему Ansible лучший друг разработчика? Потому что без него ничего не работает. С ним тоже, но хотя бы есть кого винить. 😄