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

Scrapy-паук не должен быть умным: где держать логику, чтобы проект не сгнил Типовая ошибка в Scrapy — писать весь проект внутри parse(): селекторы, нормализацию, дедупликацию, ретраи по бизнес-условиям и сохранение. Через пару изменений такой паук уже нельзя безопасно править: любая мелочь ломает соседний сценарий. Разделяйте слои: — spider: только навигация, запросы, выбор нужного парсера; — item loader / dataclass: приведение типов, чистка строк, дефолты; — pipeline: дедуп, валидация, запись, отправка дальше; — middleware: прокси, user-agent, cookies, retry-логика. Для устойчивости добавьте «контракт» данных: обязательные поля, допустимые пустые значения, формат дат и чисел. Лучше уронить item в pipeline и записать причину, чем молча отправить мусор в БД или CSV. И ещё: не смешивайте crawl-логику с бизнес-решениями. Паук не должен знать, что товар «выгодный» или лид «качественный». Он должен достать данные предсказуемо; оценку делает отдельный слой. Хороший Scrapy-проект читается сверху вниз: куда идём, что забираем, как чистим, куда кладём. Если это видно без запуска — поддержку уже упростили.