داستان پنج پاسخ به تماس

داستان پنج پاسخ به تماس

وقتی وارد می‌شوید، متوجه می‌شوید که یک مشتری سرشناس برای یک تلویزیون پنج بار از کارت اعتباری‌اش شارژ شده است، و به طور قابل‌توجهی ناراحت است. خدمات مشتری قبلاً عذرخواهی کرده و بازپرداخت را پردازش کرده است. اما رئیس شما می خواهد بداند که چگونه ممکن است این اتفاق افتاده باشد. “آیا ما برای این چیزها آزمایش نداریم!”

شما حتی کدی که نوشتید را به خاطر نمی آورید. اما شما دوباره حفاری می کنید و شروع به تلاش می کنید تا بفهمید چه چیزی ممکن است خراب شده باشد.

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

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

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

بعدش چی؟

شما در مورد آن با رئیس خود صحبت می کنید، اما او با وضعیت اوضاع احساس راحتی نمی کند. او اصرار می‌کند و شما با اکراه موافقت می‌کنید که دیگر نمی‌توانید به آنها اعتماد کنید (این چیزی است که شما را گاز می‌گیرد)، و باید بفهمید که چگونه می‌توانید دوباره از کد پرداخت در برابر چنین آسیب‌پذیری محافظت کنید.

پس از کمی سرهم بندی، کدهای ساده ای مانند کد زیر را پیاده سازی می کنید که تیم از آن راضی به نظر می رسد:

var tracked = false;
analytics.trackPurchase( purchaseData, function(){
if (!tracked) {
tracked = true;
chargeCreditCard();
displayThankyouPage();
}
} );

توجه: این باید از فصل 1 برای شما آشنا به نظر برسد، زیرا ما اساساً در حال ایجاد یک ضامن هستیم تا در صورت وجود چندین فراخوان همزمان از پاسخ به تماس ما، آن را کنترل کنیم.

اما سپس یکی از مهندسان QA شما می پرسد، “اگر هرگز با تماس تماس نگیرند چه اتفاقی می افتد؟” اوه هیچ کدام از شما به این موضوع فکر نکرده بودید.

شما شروع به تعقیب سوراخ خرگوش می کنید و به همه چیزهای احتمالی فکر می کنید که ممکن است با تماس آنها با شما اشتباه شود. در اینجا تقریباً فهرستی از راه هایی است که ابزار تجزیه و تحلیل ممکن است بد رفتار کند:

• تماس برگشتی خیلی زود (قبل از اینکه ردیابی شود)
• تماس برگشتی خیلی دیر (یا هرگز)
• پاسخ تماس را خیلی کم یا خیلی زیاد کنید (مثل مشکلی که با آن مواجه شدید!)