مسئله‌ای که باید حل می‌کردم
زنجیرهٔ هفتگی به حضور تنها وابسته نیست؛ گرفتن جایزهٔ روز قبلی هم در ادامهٔ زنجیره اهمیت داره. من این رفتار را از جایزهٔ مستقل روزانه جدا نگه داشتم.
پیاده‌سازی در نسخهٔ فعلی
WeeklyStreakRewardService.RefreshLoginState فاصلهٔ روزها و تاریخ claim قبلی را بررسی می‌کنه. فقط روز بعد همراه دریافت قبلی زنجیره را ادامه می‌دهد؛ در غیر آن روز زنجیره به یک برمی‌گردد.
تصمیم و هزینهٔ طراحی
روز هفتم می‌تواند مجموعهٔ بعد را فعال کنه. MetaCatalog تعیین می‌کنه مجموعه loop می‌شود یا یک‌بار مصرف هست و شناسهٔ مجموعهٔ کامل‌شده ذخیره می‌شود.
مرزهای فعلی
این سیاست به روز محلی و ذخیرهٔ محلی وابسته هست. برگشت ساعت یا پاک‌شدن داده می‌تواند برداشت متفاوتی بسازد؛ من از این کد حفاظت سروری در برابر دست‌کاری نتیجه نمی‌گیرم.
سناریوهای بررسی و معنای قرارداد
برای توضیح این مسیر، بازیکنی را در نظر می‌گیرم که امروز وارد می‌شود اما جایزه را دریافت نمی‌کنه. حضور او به تنهایی ضمانت رفتن به خانهٔ بعدی در فردا نیست. در منطق فعلی، مراجعهٔ روز بعد باید همراه با ثبت دریافت روز قبل باشد تا زنجیره جلو برود. این تفاوت باید در متن راهنما و حالت هر خانه دیده بشه؛ وگرنه بازیکن ممکنه ورود روزانه را شرط کافی بداند. بررسی سناریوهای روز یک، روز بعد از دریافت، روز بعد بدون دریافت و فاصلهٔ چندروزه چهار پرسش متفاوت دربارهٔ همین قرارداد هستند.
پایان روز هفتم نیز فقط یک جلوهٔ تبریک نیست، چون انتخاب مجموعهٔ بعدی به دادهٔ کاتالوگ و وضعیت مجموعه‌های کامل‌شده وابسته هست. مجموعهٔ قابل تکرار و مجموعهٔ یک‌بارمصرف انتظارات متفاوتی می‌سازند. شناسه‌ها در ذخیره اهمیت پیدا می‌کنند و تغییر بی‌قاعدهٔ آن‌ها می‌تواند معنای سابقه را عوض کنه. همانند جایزهٔ روزانه، موفقیت توزیع ممکنه درخواست نمایش معوق باشد و هنوز افزایش موجودی نباشد؛ پس دوام پاداش موضوع مستقلی هست. من این ساختار را مسیر محلی انگیزه می‌دانم و از وجود تقویم قابل اعتماد سرور یا حفاظت در برابر تغییر ساعت نتیجه نمی‌گیرم.
طراحی هفت خانه باید سابقهٔ همین مسیر را نشان بدهد، نه صرفاً تاریخ هفتهٔ واقعی رو. روز سوم زنجیره الزاماً چهارشنبه نیست و شروع تازه می‌تواند در هر روز هفته باشد. این تفاوت در توضیح کوتاه رابط مهم هست. برای من نام زنجیره با سیاست پیشروی تعریف می‌شود؛ اگر بعداً سیاست تغییر کنه، ذخیرهٔ قبلی و متن محصول هم باید آگاهانه بررسی بشن.
چیزی که از این مرحله یاد گرفتم
برای من، فرق جایزهٔ روزانه و زنجیره باید در رفتار واقعی باشد. صفحه باید نشان بدهد امروز کجای مسیر هست، نه اینکه هفت خانهٔ زیبا داشته باشد ولی معنای ادامه‌دادن روشن نباشد.
مثال عملی زنجیرهٔ پاداش هفتگی
یک روش کاربردی برای بررسی زنجیرهٔ پاداش هفتگی این است که به جای چند تغییر هم‌زمان، تنها یک مسیر کوتاه بسازی. بازیکن چند روز پیوسته می‌آید، یک روز را از دست می‌دهد و دوباره برمی‌گردد. سپس وضعیت قبل و بعد را کنار هم قرار بده. چه بخشی از داده تغییر کرده و کدام بخش فقط ظاهر تازه‌ای پیدا کرده است؟ پاسخ باید از همان تعریف موضوع بیاید. این موقعیت یک مثال آموزشی است و آمار واقعی محصول یا وعدهٔ قابلیت جدید محسوب نمی‌شود.
خطای رایج و علت آن
اگر شمارندهٔ روز و وضعیت دریافت یکی باشند، قطع زنجیره به پاداش اشتباه منجر می‌شود. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. سیاست قطع یا حفظ زنجیره باید برای بازیکن قابل فهم باشد. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
مرز روز، وقفه و رسیدن به آخر چرخه را طبق قانون ثبت‌شده بررسی کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | بازیکن چند روز پیوسته می‌آید، یک روز را از دست می‌دهد و دوباره برمی‌گردد. |
| ریسک اصلی | اگر شمارندهٔ روز و وضعیت دریافت یکی باشند، قطع زنجیره به پاداش اشتباه منجر می‌شود. |
| روش بررسی | مرز روز، وقفه و رسیدن به آخر چرخه را طبق قانون ثبت‌شده بررسی کن. |
| مرز نتیجه‌گیری | سیاست قطع یا حفظ زنجیره باید برای بازیکن قابل فهم باشد. |
پرسش‌های کاربردی دربارهٔ زنجیرهٔ پاداش هفتگی
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: بازیکن چند روز پیوسته می‌آید، یک روز را از دست می‌دهد و دوباره برمی‌گردد. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. مرز روز، وقفه و رسیدن به آخر چرخه را طبق قانون ثبت‌شده بررسی کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. سیاست قطع یا حفظ زنجیره باید برای بازیکن قابل فهم باشد.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
