Повторный запуск анализа через месяц: что ломается

За месяц меняются пути, версии библиотек и расположение файлов. Скрипт, который работал, падает или — хуже — считает не то молча. Повторный запуск нужен не только для проверки, но и для обнаружения таких изменений. Ниже — порядок действий.

Почему запуск ломается

Первое: окружение

Проверьте, что окружение собирается по файлу зависимостей. Если сборка падает, начните с этого. Не обновляйте библиотеки «чтобы заработало»: сначала поймите, какая версия была при сдаче.

Второе: пути

Абсолютные пути ломаются при переносе. Проверьте, что скрипт читает файлы относительно папки проекта. Если нет, исправьте и запишите изменение в журнал.

Третье: входные данные

Убедитесь, что данные те же: число строк, контрольная сумма, дата выгрузки. Если файл заменили, результат может отличаться по объективной причине, и это нужно зафиксировать.

Четвёртое: результат

Сравните ключевые числа с прошлым запуском. Расхождение на десятые доли может быть допустимым, крупное — сигнал проблемы. Решите заранее, какое расхождение считаете приемлемым.

Где сравнивать

Сохраняйте сводку результатов отдельно от полных таблиц. Небольшой файл с ключевыми числами позволяет сравнивать запуски за секунды и служит контрольной точкой.

Если результат не совпал

Не подгоняйте числа. Найдите причину: версия, фильтр, порядок строк, случайность. Каждую найденную причину записывайте — она пригодится в следующий раз.

Случайность

Если используется случайная выборка без фиксированного начального значения, расхождение ожидаемо. Зафиксируйте значение и перезапустите. Иначе сравнение теряет смысл.

Порядок строк

Некоторые операции зависят от порядка строк. Сортировка перед расчётом делает результат устойчивым. Это простая мера, которую часто забывают.

Когда запускать

Перед сдачей, перед публикацией и при возвращении к проекту после перерыва. Три момента, когда проверка окупается. В остальное время достаточно обычных запусков.

Сколько времени

На небольшом проекте — несколько минут. Если дольше, значит, процедура не автоматизирована. Упростите её, иначе проверку будут пропускать.

Что фиксировать после

Дата запуска, версия окружения, результат сравнения и найденные проблемы. Две-три строки в журнале. Это основание считать результат подтверждённым.

Типичные ошибки

Обновлять библиотеки при первой ошибке, не проверять данные, сравнивать на глаз, подгонять числа, не фиксировать случайность. Каждая ошибка приводит к ложному выводу о воспроизводимости.

Итог

Повторный запуск проверяет окружение, пути, данные и результат, а расхождения фиксируются в журнале, а не подгоняются.

Почему важно запускать в чистом сеансе

В интерактивной среде остаются переменные и открытые файлы с прошлых запусков. Анализ может работать не потому, что код правильный, а потому, что в памяти уже лежат нужные объекты. Запуск в чистом сеансе показывает, действительно ли скрипт самодостаточен, и выявляет скрытые зависимости от порядка действий.

Как хранить эталонный результат

Сохраните сводку ключевых чисел и небольшой файл с первыми строками результата. Полные таблицы для сравнения не нужны. Эталон приложите к проекту и обновляйте, только когда изменения осознанны и описаны в журнале. Тогда сравнение занимает секунды.

Что делать, если изменились данные

Если поставщик прислал новую версию данных, прежние числа не будут совпадать по объективной причине. Зафиксируйте версию данных, дату получения и то, чем она отличается. Не пытайтесь подогнать результат под прошлый: разница может быть содержательной и важной для выводов.

Проверка перед публикацией

Перед сдачей или публикацией пройдите три шага: чистое окружение, чистый сеанс, сравнение с эталоном. Если все три выполнены, у вас есть основание утверждать, что результат воспроизводим. Это занимает меньше часа и снимает большинство вопросов рецензентов.

Что писать в отчёте

Укажите, когда выполнялся повторный запуск, в каком окружении и совпали ли числа. Если были расхождения, опишите причину и что изменено. Короткий абзац в методах или приложении показывает, что работа проверена, а не собрана в последний момент.

Как поступить, если запуск невозможен

Иногда окружение собрать нельзя: недоступны старые версии, утеряны данные. В этом случае честно опишите ограничение и приложите максимум промежуточных данных для проверки. Скрывать проблему хуже, чем признать её: рецензент всё равно попробует повторить.

Когда повторный запуск не нужен

Для одноразового расчёта, который не будет использоваться в отчёте или публикации, проверка избыточна. Но как только результат попадает в документ или на него ссылаются коллеги, воспроизводимость становится обязательной: иначе ошибку невозможно ни подтвердить, ни опровергнуть.

Чек-лист

Окружение собирается по файлу зависимостей.
Пути относительны и работают после переноса.
Входные данные сверены по числу строк и контрольной сумме.
Запуск выполнен в чистом сеансе.
Ключевые числа сравнены с эталоном.
Причина расхождения найдена и записана.
Результат проверки отмечен в журнале.

Частые вопросы

С чего начинать?

Со сборки окружения по файлу зависимостей.

Что сравнивать?

Ключевые числа, а не все таблицы.

Что важнее всего?

Не подгонять результат под прошлый.

Пример

Через месяц анализ выдал другие цифры. Причина оказалась в порядке строк: без сортировки результат зависел от того, как файл был прочитан. После добавления сортировки значения совпали.

Итог

Повторный запуск проверяет окружение, пути, данные и результат, а причины расхождений записываются.