Amirali Yaghoutiمهندس ارشد نرم‌افزار

مطالعه موردی مهندسی

جایگزینی سفارش / اصلاح قیمت ابزارها

یک ساعت آسیب‌دیده می‌رسد و با رفرنس دیگری تعویض می‌شود. مشتری بخشی را نقد سر پیشخوان می‌پردازد. قیمتی اشتباه وارد شده. ووکامرس بعد از پرداخت سفارش برای هیچ‌کدام مسیر امنی ندارد، پس تیم مستقیم آیتم‌های سفارش را ویرایش می‌کرد که تاریخچه را از بین می‌برد و جمع‌ها را به‌هم می‌ریزد.

مسئله تجاری

ویرایش یک سفارش پرداخت‌شده در ووکامرس ممکن و خطرناک است. ادمین اجازه می‌دهد آیتم‌ها را عوض کنید ولی هیچ‌چیز ثبت نمی‌کند سفارش قبلش چه شکلی بود، و هر تغییری که جمع پرداخت را لمس کند ریسک اختلاف با چیزی را دارد که درگاه واقعاً دریافت کرده. تیم باید این سه اصلاح را به‌طور روتین انجام می‌داد و مسیر موجود هیچ undo‌ای نداشت.

آنچه تحویل دادم

  • a2-order-replacement-box.php، یک باکس ادمین سه‌هزارودویست‌ونودوچهارخطی نسخه‌ی ۱.۷.۰ که تعویض قلم با یک یا چند محصول، حمل اضافه و اصلاح قیمت همان قلم را پوشش می‌دهد.
  • یک اسنپ‌شات که پیش از هر تغییر گرفته می‌شود، با یک undo که بازش می‌گرداند، تا یک اصلاح اشتباه برگشت‌پذیر باشد نه یک تعمیر دستی دوم.
  • یک رکورد تاریخچه روی سفارش، تا توالی اصلاح‌ها ماه‌ها بعد هم خوانا باشد.
  • ثبت جداگانه‌ی دریافتی‌های خارج از درگاه، با تفکیک باقی‌مانده بین آنچه به درگاه بدهکار است و آنچه کارت‌به‌کارت آمده.
  • یک فلگ اصلاح‌شده روی سفارش، تا سفارش‌های اصلاح‌شده به‌صورت انبوه قابل شناسایی باشند نه یکی‌یکی.
  • یک قانون سخت که در خود نام افزونه آمده: وضعیت سفارش و درگاه پرداخت هرگز تغییر نمی‌کنند.

رویکرد فنی

  • اسنپ‌شات قبل از تغییر، ثابتی است که کل ابزار روی آن ساخته شده. هیچ‌چیز سفارشی را تغییر نمی‌دهد تا وضعیت قبلی ذخیره نشده باشد.
  • مرز درگاه یک امتناع عمدی است. ابزار آنچه فروشگاه بدهکار است و آنچه دریافت شده را اصلاح می‌کند؛ هیچ‌وقت سعی نمی‌کند این را به رکورد پرداخت برگرداند، چون درگاه مرجع آن چیزی است که واقعاً دریافت شده.
  • دریافتی‌های خارج از درگاه به‌عنوان دسته‌ی خودشان ثبت می‌شوند نه اینکه در جمع سفارش تا شوند، تا حسابداری بعدش قابل تفکیک بماند.
  • همه‌ی اکشن‌ها پشت یک nonce اجرا می‌شوند و هرکدام یک یادداشت سفارش می‌نویسد، پس ردپای ممیزی یک اثر جانبی استفاده از ابزار است نه مرحله‌ای که کسی باید یادش بماند.

نتیجه و شواهد

سه اصلاح روتین واقعاً روتین شدند. ثبت می‌شوند، برگشت‌پذیرند، و دیگر به کسی نیاز ندارند که با ویرایش دستی آیتم‌ها راحت باشد. تاریخچه‌ی سفارش حالا خودش را توضیح می‌دهد، که همان چیزی است که مغایرت‌گیری حسابداری را شدنی کرد.

اهمیت برای کارفرما

اینجا جایی است که عملیات به حسابداری می‌رسد. اصلاح‌ها در خرده‌فروشی جواهر همیشه قرار بود اتفاق بیفتد؛ سؤال این بود که ردی از خودشان جا می‌گذارند یا نه. حالا می‌گذارند.

خلاصه-اجرایی-پروژه

خلاصه اجرایی خوانا

خلاصه_اجرایی {
  پروژه: "Order Replacement / Price Fix Tools"
  فایل: "mu-plugins/a2-order-replacement-box.php (۳۲۹۴ خط، v1.7.0)"
  عملیات: "تعویض قلم (۱..n محصول)، افزودن حمل،
           اصلاح قیمت روی همان قلم"
  ثابت: "اسنپ‌شات پیش از تغییر؛ undo بازش می‌گرداند"
  هرگز: "وضعیت سفارش و درگاه پرداخت تغییر نمی‌کنند"
  حسابداری: "دریافتی خارج از درگاه جدا ثبت می‌شود؛
             باقی‌مانده تفکیک درگاه در برابر کارت‌به‌کارت"
  ممیزی: "تاریخچه‌ی متا + یادداشت سفارش در هر اکشن، با nonce"
  یافتن: "فلگ اصلاح‌شده تا سفارش‌های اصلاحی پیدا شوند"
}

ارزش حرفه‌ای این پروژه

مهم‌ترین خط این پروژه همان است که می‌گوید درگاه را دست نزن. خیلی راحت می‌شد اعداد را با تنظیم رکورد پرداخت مرتب نشان داد، و دقیقاً همان تغییری است که مغایرت‌گیری بعدی را غیرممکن می‌کند.

اسنپ‌شات و undo درخواست فیچر نبودند. شرطی بودند که تحت آن حاضر شدم ابزاری بدهم که سفارش‌های پرداخت‌شده را ویرایش می‌کند.