Scrapy-паук не должен быть умным: где держать логику, чтобы проект не сгнил

Scrapy-паук не должен быть умным: где держать логику, чтобы проект не сгнил

Типовая ошибка в Scrapy — писать весь проект внутри parse(): селекторы, нормализацию, дедупликацию, ретраи по бизнес-условиям и сохранение. Через пару изменений такой паук уже нельзя безопасно править: любая мелочь ломает соседний сценарий.

Разделяйте слои:
— spider: только навигация, запросы, выбор нужного парсера;
— item loader / dataclass: приведение типов, чистка строк, дефолты;
— pipeline: дедуп, валидация, запись, отправка дальше;
— middleware: прокси, user-agent, cookies, retry-логика.

Для устойчивости добавьте «контракт» данных: обязательные поля, допустимые пустые значения, формат дат и чисел. Лучше уронить item в pipeline и записать причину, чем молча отправить мусор в БД или CSV.

И ещё: не смешивайте crawl-логику с бизнес-решениями. Паук не должен знать, что товар «выгодный» или лид «качественный». Он должен достать данные предсказуемо; оценку делает отдельный слой.

Хороший Scrapy-проект читается сверху вниз: куда идём, что забираем, как чистим, куда кладём. Если это видно без запуска — поддержку уже упростили.