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