مسئله‌ای که باید حل می‌کردم
در حکم، بازیکن حاکم باید پیش از دیدن همهٔ دست حکم را انتخاب کنه. اگر تمام سیزده کارت را یک‌باره بدهم، همان اطلاعات محدود مرحلهٔ انتخاب از بین می‌رود.
پیاده‌سازی در نسخهٔ فعلی
HokmDealFlowService.DealFirstBatch پنج کارت برای هر صندلی می‌دهد. DealRemainingBatches دو بستهٔ چهار کارتی را تنها بعد از انتخاب حکم ادامه می‌دهد؛ پایان باید سیزده کارت برای هر نفر و دستهٔ خالی باشد.
تصمیم و هزینهٔ طراحی
به جای تغییر CardDealer عمومی، این سرویس ترتیب تخصصی حکم را نگه می‌دارد. شمارش هر مرحله بررسی می‌شود و انتخاب حکم یک توقف واقعی در جریان هست.
مرزهای فعلی
سرویس دستهٔ ۵۲ کارتی و چهار assignment متمایز می‌خواهد. از بررسی منطقی تعدادها نمی‌توان درست‌بودن انیمیشن پرواز کارت یا جای کارت در Canvas را نتیجه گرفت.
پنج کارت به‌عنوان مرز اطلاعات
در ابتدای دست، DealFirstBatch پیش از برداشت، دست‌های قبلی را پاک می‌کنه و RuntimeDeck را Reset می‌کنه. پس از آن شرط ۵۲ کارت بررسی می‌شود و در صورت درخواست، دسته بر می‌خورد. این ترتیب به خواننده نشان می‌دهد چرا نباید مرحلهٔ انتخاب حاکم را با تقسیم نهایی مخلوط کنه: هر مرحله آغاز منطقی خود را داره. BuildAssignmentMap نیز چهار تخصیص صندلی متمایز می‌خواهد. داشتن چهار شیء در فهرست کافی نیست؛ اگر یک صندلی تکرار شده باشد، تقسیم باید متوقف بشه تا کارت‌های یک نفر جای فرد دیگر را پر نکنند.
پنج کارت برای هر صندلی یعنی بیست کارت خارج شده و سی‌ودو کارت در دسته مانده هست. ValidateFirstBatchResult همین نسبت را در خروجی بررسی می‌کنه و RequiresTrumpSelection را نیز لازم می‌داند. این عددها تنها آمار جانبی نیستند؛ پایان مرحله و محدودهٔ اطلاعات حاکم را مشخص می‌کنند. کارت‌ها در DealCardsToEachSeat به‌صورت دورگرد داده می‌شوند، نه پنج کارت پیوسته برای هر نفر. بنابراین ترتیب شروع از حاکم، جهت صندلی‌ها و ترتیب دسته همگی در ترکیب دست‌های واقعی اثر دارن و باید با هم خوانده بشن.
DealRemainingBatches ورودی trumpSelected را بررسی می‌کنه و انتظار داره هر دست هنوز پنج کارت داشته باشد. سپس دو نوبت چهارکارتی اجرا می‌شود و خروجی نهایی باید سیزده کارت برای هر نفر و صفر کارت باقی‌مانده داشته باشد. این تابع خودِ تصمیم حکم را نمی‌گیرد و درست بودن مقدار بولی ورودی به مسیر فراخوانی وابسته هست. همچنین همهٔ بررسی‌ها بازگردانی خودکار وضعیت نمی‌سازند؛ اگر پس از بخشی از برداشت مشکلی رخ دهد، نباید صرفاً از روی وجود Validate انتظار rollback داشت. اتصال مرحله‌ها باید وضعیت خطا و شروع دوباره را آگاهانه مدیریت کنه.
چیزی که از این مرحله یاد گرفتم
این مرحله یادم داد که پخش کارت فقط تقسیم‌کردن نیست؛ مقدار اطلاعاتی که بازیکن در هر لحظه داره هم بخشی از قانون هست و باید در معماری قابل دیدن بماند.
مثال عملی پخش مرحله‌ای حکم
اگر بخواهی پخش مرحله‌ای حکم را در یک پروژهٔ کوچک بررسی کنی، بهتر است از یک موقعیت محدود شروع کنی. ابتدا بخشی از دست را نشان بده، انتخاب حکم را دریافت کن و بعد پخش را ادامه بده. ورودی را ثابت نگه دار و نتیجهٔ مورد انتظار را پیش از اجرای نسخه بنویس. این کار کمک می‌کند تفاوت میان رفتار منطقی و چیزی که صرفاً روی صفحه دیده می‌شود روشن بماند. سناریوی این بخش آموزشی است و ادعای نتیجهٔ واقعی یک آزمایش روی کاربران دلو ندارد.
خطای رایج و علت آن
اجرای همهٔ پخش پیش از انتخاب خال، مرز تصمیم بازیکن را از بین می‌برد. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. پخش مرحله‌ای یک حالت منطقی است و نباید فقط تأخیر در انیمیشن باشد. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
تعداد کارت هر مرحله و ممنوع بودن بازی پیش از کامل شدن پخش را بررسی کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | ابتدا بخشی از دست را نشان بده، انتخاب حکم را دریافت کن و بعد پخش را ادامه بده. |
| ریسک اصلی | اجرای همهٔ پخش پیش از انتخاب خال، مرز تصمیم بازیکن را از بین می‌برد. |
| روش بررسی | تعداد کارت هر مرحله و ممنوع بودن بازی پیش از کامل شدن پخش را بررسی کن. |
| مرز نتیجه‌گیری | پخش مرحله‌ای یک حالت منطقی است و نباید فقط تأخیر در انیمیشن باشد. |
پرسش‌های کاربردی دربارهٔ پخش مرحله‌ای حکم
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: ابتدا بخشی از دست را نشان بده، انتخاب حکم را دریافت کن و بعد پخش را ادامه بده. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. تعداد کارت هر مرحله و ممنوع بودن بازی پیش از کامل شدن پخش را بررسی کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. پخش مرحله‌ای یک حالت منطقی است و نباید فقط تأخیر در انیمیشن باشد.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
