مسئله‌ای که باید حل می‌کردم
پاسور را هم‌تیمی‌ام نوشت. نقش من در روایت دلو، توضیح وصل‌شدن آن کار به ساختار مشترک هست؛ نه اینکه منطق نوشته‌شدهٔ او را به نام خودم تعریف کنم.
پیاده‌سازی در نسخهٔ فعلی
PasurSceneRunner بازی، رابط دست و زمین، حرکت کارت، انتخاب حالت و نتیجه را هماهنگ می‌کنه. PasurGame از RuntimePlayer، RuntimeDeck و CardInstance مشترک استفاده می‌کنه و قوانین در فضای Pasur می‌مونن.
تصمیم و هزینهٔ طراحی
استفاده از JokerHandView و سیستم تنظیمات مشترک نشان می‌دهد reuse فقط در هستهٔ منطقی نیست. با این حال runner تخصصی پاسور همچنان مسئول ترتیب capture و پایان دور هست.
مرزهای فعلی
سازگارشدن چند component به معنای حذف تمام وابستگی‌ها نیست. referenceهای صحنه، حالت دو یا چهار نفر و ورودی زمین باید در پروژهٔ کامل بررسی بشن.
سناریوهای بررسی و معنای قرارداد
در روایت این پروژه، نوشتن قانون پاسور را به هم‌تیمی‌ام نسبت می‌دهدم. آنچه برای من در این مرحله ارزش بررسی داره، مرز ورود آن کار به ساختار دلو هست: یک بازی تازه باید کارت، بازیکن و دستهٔ مشترک را بفهمد و در عین حال قانون اختصاصی خود را حفظ کنه. استفاده از RuntimePlayer، RuntimeDeck و CardInstance این زبان مشترک را نشان می‌دهد. اما جمع کردن کارت‌های زمین، حالت دو یا چهار نفره و پایان دور مسئله‌های پاسور هستند و به runner تخصصی نیاز دارن. استفادهٔ مشترک به معنای یکسان کردن همهٔ جریان‌های بازی نیست.
مثال عملی همکاری، تغییر ظاهر کارت یا تنظیمات مشترک هست. وقتی جزء مشترک قرارداد روشن داره، بازی تازه می‌تواند آن را مصرف کنه بدون اینکه کد قانونش برای هر پوست تغییر کنه. با این حال ارجاع صحنه، اتصال دست و میز و ورودی باید در پروژهٔ کامل بررسی بشه؛ داشتن کلاس هم‌نام کافی نیست. بازاستفاده از JokerHandView نیز نیاز به توجه به رفتار اختصاصی دست پاسور داره. من از این سورس نتیجه می‌گیرم که نقاط اتصال قابل مشاهده‌اند، نه اینکه همهٔ سناریوهای دستگاه واقعی آزموده شده‌اند. این نگاه اعتبار کار هم‌تیمی را حفظ می‌کنه و سهم بررسی و یکپارچه‌سازی را با ادعای نوشتن کل بازی مخلوط نمی‌کنه.
مرز مسئولیت در نوشتن یادداشت نیز بخشی از همکاری هست. می‌توانم دربارهٔ اتصال تنظیم، ورود و نمایش مشترک صحبت کنم و هم‌زمان کد اختصاصی پاسور را با نام صاحب کار توضیح بدهم. این دقت خواننده را از برداشت نادرست دربارهٔ نویسندگی حفظ می‌کنه. برای من یکپارچگی پروژه از داشتن قرارداد مشترک می‌آید، نه از اینکه همهٔ فایل‌ها را یک نفر نوشته باشد یا همهٔ بازی‌ها یک runner داشته باشند.
چیزی که از این مرحله یاد گرفتم
برای من، این مرحله معیار عملی همکاری بود. اگر قراردادهای مشترک روشن باشند، هم‌تیمی می‌تواند بازی خودش را اضافه کنه و من دربارهٔ مرز ادغام و تجربهٔ محصول تصمیم بگیرم، بدون ادعای مالکیت کار او.
مثال عملی ادغام پاسور در هسته
برای فهم عملی ادغام پاسور در هسته، یک مثال آموزشی را قدم‌به‌قدم دنبال کنیم. منطق جمع‌کردن پاسور را به نمایش کارت مشترک وصل کن و مسئولیت هر بخش را مشخص کن. پیش از اجرا، وضعیت آغاز را روی کاغذ بنویس؛ مشخص کن چه چیزی می‌تواند تغییر کند و چه چیزی باید ثابت بماند. بعد فقط همین مسیر را اجرا کن. این مثال گزارشی از آمار کاربران یا قابلیت تازهٔ منتشرشدهٔ دلو نیست؛ تمرینی برای روشن کردن تصمیم طراحی همین مطلب است.
خطای رایج و علت آن
اشتراک نمایش نباید قانون حکم یا جوکر را وارد امتیاز پاسور کند. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. قرارداد ادغام باید برای نویسندهٔ قانون و نویسندهٔ نمایش قابل خواندن باشد. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
کارت‌های زمین، انتخاب جمع‌آوری و نتیجهٔ امتیاز را مستقل از ظاهر بررسی کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | منطق جمع‌کردن پاسور را به نمایش کارت مشترک وصل کن و مسئولیت هر بخش را مشخص کن. |
| ریسک اصلی | اشتراک نمایش نباید قانون حکم یا جوکر را وارد امتیاز پاسور کند. |
| روش بررسی | کارت‌های زمین، انتخاب جمع‌آوری و نتیجهٔ امتیاز را مستقل از ظاهر بررسی کن. |
| مرز نتیجه‌گیری | قرارداد ادغام باید برای نویسندهٔ قانون و نویسندهٔ نمایش قابل خواندن باشد. |
پرسش‌های کاربردی دربارهٔ ادغام پاسور در هسته
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: منطق جمع‌کردن پاسور را به نمایش کارت مشترک وصل کن و مسئولیت هر بخش را مشخص کن. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. کارت‌های زمین، انتخاب جمع‌آوری و نتیجهٔ امتیاز را مستقل از ظاهر بررسی کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. قرارداد ادغام باید برای نویسندهٔ قانون و نویسندهٔ نمایش قابل خواندن باشد.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
