مسئله‌ای که باید حل می‌کردم
کشیدن کارت جوکر چند مرحله داره: انتقال، جفت احتمالی، شافل و رفتن نوبت. اگر هر مرحله جدا درخواست تازه بپذیرد، مدل و نمایش به راحتی از هم فاصله می‌گیرندد.
پیاده‌سازی در نسخهٔ فعلی
JokerGame.TryDraw انتقال منطقی را انجام می‌دهد و یک pendingMove می‌سازد. تا CompleteMove همان حرکت کامل نشود، حرکت تازه رد می‌شود؛ جفت احتمالی باید واقعاً از دست حذف شده باشد.
تصمیم و هزینهٔ طراحی
runner همان view را جدا می‌کنه و منتقل می‌کنه، سپس جفت را نمایش می‌دهد و فقط دست گیرنده را شافل می‌کنه. ترتیب از نتیجهٔ پذیرفته‌شده می‌آید، نه از حدس انیمیشن.
مرزهای فعلی
pendingMove تراکنش سروری یا rollback خودکار نیست. توقف و restart باید coroutine و tween و viewهای باقی‌مانده را تمیز کنن؛ token نسخهٔ runner برای مسیر قدیمی اهمیت داره.
سناریوهای بررسی و معنای قرارداد
یک حرکت پذیرفته‌شده بیش از جابه‌جایی فوری یک کارت هست. ممکنه در دست گیرنده جفت ساخته بشه، آن جفت از دست خارج بشه، ترتیب دست تغییر کنه و سپس نوبت ادامه پیدا کنه. pendingMove اجازه می‌دهد این مراحل به یک عمل مشخص تعلق داشته باشند. اگر بازیکن وسط نمایش دوباره لمس کنه، مدل نباید حرکت تازه‌ای را روی حالت نیمه‌نمایش‌یافته بپذیرد. شرط خروج واقعی کارت‌های جفت از دست گیرنده در CompleteMove نیز اهمیت داره: نمایش حذف بدون تغییر مدل برای پایان حرکت کافی نیست. این مرز کمک می‌کنه نتیجهٔ منطقی و تصویر روی میز از هم جدا نشوند.
در سمت اجرا، انتقال همان نمای جداشده باعث می‌شود هویت کارت در مسیر حفظ بشه. توکن نسخهٔ runner نیز برای زمانی اهمیت داره که یک توالی قدیمی پس از توقف یا شروع مجدد هنوز منتظر ادامه هست. چنین توالی‌ای نباید به بازی جدید دست بزند. با این حال این ساختار rollback خودکار یا تراکنش پایگاه داده نیست؛ هر توقف باید tween، coroutine و نمای بدون صاحب را درست جمع کنه. سناریوی بررسی شامل توقف هنگام انتقال، توقف هنگام حذف جفت و شروع دوباره هست. من از وجود قفل حرکت، سالم بودن همهٔ مسیرهای لغو را نتیجه نمی‌گیرم؛ آن‌ها بخش مستقلی از کیفیت جریان هستند.
پذیرش حرکت و پایان نمایش باید در گزارش هم جدا باشند. لمس کاربر فقط درخواست هست و نتیجهٔ TryDraw نشانهٔ پذیرش مدل؛ پایان انیمیشن نشانهٔ دیگری هست. اگر این مراحل یکی نام‌گذاری بشن، توقف ارائه می‌تواند به اشتباه رد قانون تعبیر بشه. این اصل از ساختار pendingMove می‌آید و برای بررسی خطا مفید هست، بدون آنکه وجود سامانهٔ گزارش ویژهٔ هر مرحله را در پروژه ادعا کنم.
چیزی که از این مرحله یاد گرفتم
برای من، تراکنش اینجا یعنی یک حرکت پذیرفته‌شده با آغاز و پایان مشخص. این قرارداد اجازه می‌دهد انیمیشن زمان داشته باشد، بدون اینکه لمس بعدی وسط نمایش قانون را دوباره اجرا کنه.
مثال عملی انتقال کارت جوکر
اگر بخواهی انتقال کارت جوکر را در یک پروژهٔ کوچک بررسی کنی، بهتر است از یک موقعیت محدود شروع کنی. یک کارت از دست حریف برداشته می‌شود، جفت احتمالی حذف می‌شود و دست دوباره بر می‌خورد. ورودی را ثابت نگه دار و نتیجهٔ مورد انتظار را پیش از اجرای نسخه بنویس. این کار کمک می‌کند تفاوت میان رفتار منطقی و چیزی که صرفاً روی صفحه دیده می‌شود روشن بماند. سناریوی این بخش آموزشی است و ادعای نتیجهٔ واقعی یک آزمایش روی کاربران دلو ندارد.
خطای رایج و علت آن
اگر هر گام مستقل باشد، کلیک دوباره می‌تواند کارت را دو بار منتقل کند. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. انتقال، حذف جفت و تعیین نوبت باید یک تغییر منطقی کامل بسازند. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
تعداد کل کارت، مالکیت و حذف جفت را قبل و بعد از عملیات مقایسه کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | یک کارت از دست حریف برداشته می‌شود، جفت احتمالی حذف می‌شود و دست دوباره بر می‌خورد. |
| ریسک اصلی | اگر هر گام مستقل باشد، کلیک دوباره می‌تواند کارت را دو بار منتقل کند. |
| روش بررسی | تعداد کل کارت، مالکیت و حذف جفت را قبل و بعد از عملیات مقایسه کن. |
| مرز نتیجه‌گیری | انتقال، حذف جفت و تعیین نوبت باید یک تغییر منطقی کامل بسازند. |
پرسش‌های کاربردی دربارهٔ انتقال کارت جوکر
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: یک کارت از دست حریف برداشته می‌شود، جفت احتمالی حذف می‌شود و دست دوباره بر می‌خورد. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. تعداد کل کارت، مالکیت و حذف جفت را قبل و بعد از عملیات مقایسه کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. انتقال، حذف جفت و تعیین نوبت باید یک تغییر منطقی کامل بسازند.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
