Автоматизация ломается не в коде, а в предположениях о данных

Автоматизация ломается не в коде, а в предположениях о данных

Чаще всего скрипт пишут под «идеальный» вход: один формат даты, один тип файла, один ответ API. Потом прилетает пустое поле, лишний пробел или другой порядок колонок — и весь пайплайн молча едет в мусор.

За неделю в репах я бы проверял 4 вещи:
— явная схема входа: pydantic, проверки типов, обязательные поля;
— идемпотентность: повторный запуск не должен дублировать записи;
— раздельные ошибки: парсинг, сеть, запись в БД, внешние лимиты;
— логирование с контекстом: что пришло, на каком шаге упало, какой ключ сломан.

Отдельная ловушка — «тихие» падения. Скрипт завершился успешно, но половина строк не обработалась, потому что фильтр слишком узкий или исключение проглотили в helper-функции. Для automation это хуже явного traceback: потом нечего расследовать.

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