Python Web & Scripts — Django, FastAPI, скрипты
Автоматизация ломается не в коде, а в предположениях о входных данных
Скрипт для парсинга, отчётов или синхронизации обычно пишут под «нормальный» кейс: один формат, одна схема, один источник. Потом в бою прилетает пустое поле, лишний символ, дубль или таймаут — и пайплайн молча портит данные.
Что помогает держать автоматизацию живой:
— валидировать вход на границе: pydantic, явные проверки, whitelist полей;
— делать операции идемпотентными: повторный запуск не должен плодить дубли;
— отделять сбор данных от записи: сначала сырой слой, потом преобразование;
— логировать не только ошибки, но и «подозрительные успехи»: пустые ответы, частичные выборки, неожиданные типы.
Ещё одна типовая ошибка — смешивать бизнес-логику и инфраструктуру. Когда парсер сам решает, как ретраить, как маппить поля и куда слать уведомление, его трудно тестировать и ещё труднее менять. Лучше держать шаги отдельно: fetch → validate → transform → store → notify.
Если автоматизация должна жить долго, проектируйте её как набор маленьких повторяемых операций, а не как один «магический» скрипт: так она переживёт любой шум во входных данных.
2 ·