مطالعه موردی مهندسی
اتوماسیون موجودی Excel دیجیکالا
بررسی چند هزار محصول در برابر فهرستهای مارکتپلیسشان با دست کاری است که هیچکس دو بار تمامش نمیکند. مهندسی جالب اینجا اسکرپینگ نیست، قابلتحملکردن یک اجرای طولانی است: کش میکند، پیشرفت را همانطور که پیش میرود لاگ میکند، و میشود متوقفش کرد و ادامه داد.
مسئله تجاری
فایل موجودی و فهرستهای مارکتپلیس مدام از هم فاصله میگیرند، و تطبیقشان با دست روزها طول میکشد و بسته به اینکه چه کسی انجامش داده جواب متفاوتی میدهد. خودکارکردنش به محدودیت واقعی میخورد: یک اجرا روی هزاران محصول ساعتها طول میکشد، و هر چیزی که وسط راه بدون نوشتن چیزی شکست بخورد از بیفایده هم بدتر است.
آنچه تحویل دادم
- یک خط لولهی پایتون که فایل موجودی را با pandas میخواند و یک فایل وضعیت برمیگرداند، تا ورودی و خروجی هر دو فایلهایی باشند که تیم عملیات از قبل با آنها کار میکند.
- یک کش JSON پایدار از هر جستوجو، که همان چیزی است که یک اجرا را قابلازسرگیری میکند نه قابلشروعمجدد.
- یک CSV پیشرفت فقط-افزودنی که در حین اجرا نوشته میشود، تا نتایج جزئی از یک وقفه جان سالم بهدر ببرند و اجرا در حین انجام قابل پایش باشد.
- یک مسیر مرورگر Playwright برای فهرستهایی که به رندر نیاز دارند، با requests و BeautifulSoup برای آنهایی که ندارند.
- یک راهبرد جستوجو-و-تأیید با تطبیق دقیق اسلاگ و یک فالبک جستوجو، بهجای اعتماد به یک مسیر جستوجوی واحد.
- فاصلهگذاری تصادفی بین درخواستها، چون اسکرپری که یک مارکتپلیس را میکوبد بلاک میشود و آنوقت کل اجرا بیارزش است.
- یک مهر نسخه در سورس، تا یک فایل خروجی مشخص به منطقی که تولیدش کرده ردیابی شود.
رویکرد فنی
- کش تصمیم طراحی اصلی است. هر محصول resolveشده فوری روی دیسک نوشته میشود، که یک اجرای شکنندهی چندساعته را تبدیل به چیزی میکند که آزادانه میشود قطعش کرد.
- پیشرفت افزوده میشود نه اینکه در حافظه نگه داشته و در انتها نوشته شود. یک کرش در ۹۰ درصد باید آخرین محصول را هزینه کند نه کل اجرا را.
- دو راهبرد دریافت بهجای یکی: اول مسیر ارزان HTTP امتحان میشود و مرورگر فقط جایی استفاده میشود که واقعاً لازم است، چون راهاندازی یک مرورگر بهازای هر محصول اجرا را غیرممکن میکرد.
- تطبیق تأیید میشود نه فرض. تطبیق دقیق اسلاگ ترجیح دارد و وقتی شکست بخورد فالبک جستوجو استفاده میشود، چون یک تطبیق با اطمینانِ غلط از نبود تطبیق بدتر است.
- تأخیرهای تصادفی اینجا یک الزام درستیاند نه ادب. یک اجرای بلاکشده دادهی بد تولید میکند نه دادهی کند.
نتیجه و شواهد
تطبیق تبدیل به یک اجرا شد نه یک پروژه. خروجی یک فایل وضعیت است که تیم عملیات مستقیم بازش میکند، و کش یعنی اجرای دوباره بعد از یک شکست جزئی بهجای ساعتها دقیقه هزینه دارد.
اهمیت برای کارفرما
این تفاوت بین بررسیای است که چون دردناک است فصلی انجام میشود و بررسیای که هر وقت لازم شد انجام میشود.
خلاصه اجرایی خوانا
خلاصه_اجرایی {
پروژه: "Digikala Excel Inventory Automation"
پشته: "Python، pandas، requests، BeautifulSoup، Playwright"
ورودی_خروجی: "اکسل موجودی به داخل، اکسل وضعیت به بیرون"
ازسرگیری: "کش JSON پایدار + CSV پیشرفت فقط-افزودنی،
نوشتهشده در حین اجرا"
دریافت: "اول HTTP؛ مرورگر headless فقط جایی که لازم است"
تطبیق: "اسلاگ دقیق ترجیح دارد، فالبک جستوجو، تأییدشده"
فاصلهگذاری: "تأخیر تصادفی؛ اجرای بلاکشده دادهی بد است"
ردیابی: "نسخهی وصله در سورس مهر خورده"
}ارزش حرفهای این پروژه
قابلیت ازسرگیری چیزی است که دوست دارم دیده شود. نوشتن اسکرپینگ از هرکسی برمیآید؛ طراحی یک جاب طولانی طوری که یک وقفه ارزان باشد بخشی است که تعیین میکند آیا اصلاً بار دوم استفاده میشود.
ترجیح مسیر ارزان دریافت و بالا رفتن به مرورگر فقط در صورت نیاز، همان غریزه است که روی هزینه اعمال شده.