سکه را در یک نقطه تغییر دادم

مسئله‌ای که باید حل می‌کردم

با اضافه‌شدن جایزه و خرید، تغییر مستقیم سکه از چند صفحه می‌تونست آمار و موجودی را از هم جدا کنه. من مسیر افزایش و خرج را در یک سرویس متمرکز کردم.

پیاده‌سازی در نسخهٔ فعلی

CurrencyService.AddCoins موجودی و totalCoinsEarned را زیاد می‌کنه. TrySpendCoins ابتدا CanAfford را بررسی می‌کنه و سپس موجودی و totalCoinsSpent را تغییر می‌دهد؛ هر مسیر ذخیره و CoinsChanged را اجرا می‌کنه.

تصمیم و هزینهٔ طراحی

CurrencyChangeReason علت تغییر را همراه رویداد می‌برد و GameplayTelemetry همان تغییر را می‌بینه. ظاهر هدر می‌تواند واکنش نشان بدهد، بدون اینکه خودش حساب سکه را مدیریت کنه.

مرزهای فعلی

این حسابداری محلی هست و integer استفاده می‌کنه. سرویس قفل هم‌زمانی یا اعتبارسنجی سروری نداره؛ SetCoinsForDebug هم مسیر متفاوتی هست که جمع درآمد و خرج را بازنویسی نمی‌کنه.

سناریوهای بررسی و معنای قرارداد

برای روشن کردن قرارداد، می‌شود موجودی فرضی صد سکه و خریدی به قیمت سی سکه را در نظر گرفت. این اعداد نمونهٔ توضیح هستند، نه دادهٔ بازیکنان. خرید موفق باید هم موجودی را هفتاد کنه و هم مجموع هزینه را سی واحد افزایش بدهد. اگر صفحهٔ فروشگاه تنها عدد نمایشی را کم کنه، دستاورد مرتبط با هزینه و ذخیرهٔ بعدی با آن هم‌نظر نخواهند بود. مسیر TrySpendCoins این چند اثر را در یک نقطه کنار هم نگه می‌دارد. خریدی گران‌تر از موجودی نیز باید پیش از تغییر داده رد بشه تا رابط بتواند دلیل شکست را نمایش بدهد.

در کد، مبلغ غیرمثبت برای خرج کردن موفق تلقی می‌شود و افزودن مبلغ غیرمثبت هیچ اثری نداره. این جزئیات یعنی اعتبارسنجی تعریف کالا همچنان مسئولیت مهمی داره؛ موفق بودن تابع برای مبلغ صفر، درستی قیمت‌گذاری را ثابت نمی‌کنه. همچنین مسیر دیباگ موجودی را تغییر می‌دهد اما تاریخچهٔ کسب و خرج را بازسازی نمی‌کنه. بنابراین هنگام خواندن گزارش یا آزمایش دستاورد، باید بدانم داده از بازی عادی آمده یا از ابزار توسعه. مرکزیت سرویس مسئلهٔ هماهنگی محلی را ساده می‌کنه، اما برای برخورد با دستکاری فایل یا رقابت چند دستگاه به قرارداد دیگری نیاز هست.

یکی از نکته‌های گزارش، تفاوت تغییر موجودی با موجودی نهایی هست. افزودن جایزه و خرید پشت سر هم ممکنه به همان عدد آغاز برگردند، ولی دو رفتار واقعی رخ داده‌اند. دلیل و تغییر هر مرحله برای فهم جریان اقتصاد مهم هست. این سرویس آن‌ها را قابل بیان می‌کنه؛ با این حال نگهداری حسابرسی بلندمدت و تطبیق با منبع مستقل از همین رویداد محلی نتیجه نمی‌شود.

چیزی که از این مرحله یاد گرفتم

برای من، عدد سکه وقتی قابل اعتمادتر شد که همهٔ تغییرها دلیل و مسیر روشن داشتند. این پایه برای ورود به مسابقه، پاداش و شخصی‌سازی لازم بود، پیش از اینکه دربارهٔ زیبایی فروشگاه فکر کنم.

مثال عملی دفتر تغییر سکه

یک روش کاربردی برای بررسی دفتر تغییر سکه این است که به جای چند تغییر هم‌زمان، تنها یک مسیر کوتاه بسازی. برای ورود و جایزه، مقدار موجودی پیش و پس از تغییر و دلیل تراکنش را ثبت کن. سپس وضعیت قبل و بعد را کنار هم قرار بده. چه بخشی از داده تغییر کرده و کدام بخش فقط ظاهر تازه‌ای پیدا کرده است؟ پاسخ باید از همان تعریف موضوع بیاید. این موقعیت یک مثال آموزشی است و آمار واقعی محصول یا وعدهٔ قابلیت جدید محسوب نمی‌شود.

خطای رایج و علت آن

تغییر مستقیم سکه در چند بخش، پیدا کردن پاداش تکراری یا کسر اشتباه را سخت می‌کند. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. نمایش موجودی از مرجع تغییر موجودی پیروی می‌کند. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.

چطور نتیجه را بررسی کنیم؟

هر تغییر باید دلیل و مقدار معلوم داشته باشد و موجودی منفی ناخواسته تولید نکند. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.

پرسش‌های کاربردی دربارهٔ دفتر تغییر سکه

از کجا شروع کنم؟

از همان موقعیت محدود این مطلب شروع کن: برای ورود و جایزه، مقدار موجودی پیش و پس از تغییر و دلیل تراکنش را ثبت کن. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.

چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟

زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. هر تغییر باید دلیل و مقدار معلوم داشته باشد و موجودی منفی ناخواسته تولید نکند. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. نمایش موجودی از مرجع تغییر موجودی پیروی می‌کند.