Splync v1.5 — نسبت‌های تقسیم قابل تنظیم برای پروژه و دسته‌بندی

در ۱۶ سپتامبر ۲۰۲۵، Splync v1.5 منتشر شد — تنها چهار روز پس از آنکه ازدواج بین‌المللی ما توسط شهر پذیرفته شد. تا قبل از این به‌روزرسانی، Splync نمی‌توانست نسبت‌های تقسیم را تنظیم کند؛ به طور پیش‌فرض، هر هزینه به طور مساوی تقسیم می‌شد. با v1.5، کاربران می‌توانند نسبت‌های مخصوص به پروژه و دسته را تنظیم کنند. این تغییر به زوج‌ها و دوستان اجازه می‌دهد هزینه‌های مشترک خود را به گونه‌ای تقسیم کنند که بهتر بازتاب‌دهنده زندگی واقعی‌شان باشد، نه صرفاً یک تقسیم ساده ۵۰:۵۰. شما می‌توانید یک پروژه حسابداری جدید را از اکتبر با تقسیم ۶۰:۴۰ برای هزینه‌های روزمره آغاز کنید، در حالی که اجاره آپارتمان خود را در همان ۵۰:۵۰ نگه دارید اگر به نظر شما عادلانه است. و اگر مواد غذایی به نظر می‌رسد در ۷۰:۳۰ و خدمات عمومی بهتر است در ۶۲:۳۸ باشد، حالا می‌توانید این نسبت‌ها را به صورت جداگانه — دسته به دسته — در همان پروژه تنظیم کنید.

تغییر قابل مشاهده در v1.5 بخش جدیدی به نام اعضا و سهام پیش‌فرض است که در آن می‌توانید اعضای پروژه را اضافه کرده و سهم پیش‌فرض هر فرد را تخصیص دهید. اگر پروژه دو عضو داشته باشد، نسبت می‌تواند ۵۰:۵۰، ۴۰:۶۰ یا هرچه به نظر درست می‌رسد باشد. با سه عضو، می‌تواند ۳۳.۳۳:۳۳.۳۳:۳۳.۳۴، ۵۰:۲۵:۲۵ یا هر ترکیبی باشد که شما ترجیح می‌دهید. این تبدیل به تقسیم پیش‌فرض پروژه می‌شود. در زیر آن، می‌توانید پایین بروید و سهم هر دسته را تنظیم کنید اگر می‌خواهید با پیش‌فرض پروژه متفاوت باشد. وقتی نسبت سفارشی به یک دسته تخصیص می‌دهید، نشانگر نسبت آبی آن به نارنجی تبدیل می‌شود — نشانه بصری کوچکی که نشان می‌دهد دسته از قاعده خود استفاده می‌کند نه قاعده کلی پروژه. در حالی که این تغییر انعطاف‌پذیری بیشتری به تنظیمات پروژه می‌دهد، همچنین نمایش ایجاد/ویرایش پروژه را کمی پیچیده‌تر می‌کند. برای کمک به این کار، دکمه‌های اطلاعاتی به هر بخش اضافه کردم تا بتوانید با ضربه زدن بر روی آنها به کمک‌های کوچک سؤالات و پاسخ‌ها دسترسی پیدا کنید.

اجرای این تغییر پیچیده‌تر از آن بود که انتظار داشتم. Splync همیشه دنیای تمیز ۵۰:۵۰ را فرض کرده بود — یک عدد، به همه جا اعمال می‌شد و محاسبات انجام می‌شد. وقتی تصمیم گرفتم نسبت‌های سفارشی را پشتیبانی کنم، کل ساختار داخلی باید بازاندیشی می‌شد. یک پروژه دیگر نمی‌توانست به یک درصد مشترک تکیه کند. هر دسته نیاز به نسبت خود داشت و هر هزینه باید هم به پیش‌فرض پروژه و هم به جایگزینی دسته ارجاع می‌کرد. برای انجام این کار، من منطق محاسبات را از پایه بازنویسی کردم. هر هزینه اکنون یک درخت تصمیم کوچک دارد: «آیا این دسته نسبت خود را دارد؟ اگر بله، از آن استفاده کن. اگر نه، به نسبت پروژه برگرد.» وقتی توضیحش می‌دهی ساده به نظر می‌رسد، اما حفظ مدل داده سازگار در سراسر اپلیکیشن — نمایش‌های iOS، بک‌اند FastAPI و طرح‌های MariaDB — نیاز به تنظیمات دقیق‌تری از آنچه انتظار داشتم داشت.

هر به‌روزرسانی که به سمت سرور دست می‌زند باید با دقت شدیداً انجام شود. اگر به طور اتفاقی کد موجود سرور را تغییر دهید، کاربرانی که هنوز از v1.4 استفاده می‌کنند بلافاصله با باگ‌ها یا خطاهای سیستمی روبه‌رو می‌شوند. برای مثال، برنامه سرور برای v1.5 انتظار دارد تنظیمات پروژه شامل داده‌های نسبت باشد، اما برنامه v1.4 تنظیمات پروژه را بدون هیچ نسبتی ارسال می‌کند. لحظه‌ای که این دو نسخه تلاش می‌کنند ارتباط برقرار کنند، درخواست شکست می‌خورد — چون به سادگی «زبان» کمی متفاوتی صحبت می‌کنند. توسعه‌دهندگان می‌توانند به طور ایمن تغییرات را در یک محیط آزمایشی انجام دهند. بخش دشوار پس از ارسال نسخه جدید برای بررسی اپل آغاز می‌شود در حالی که کاربران موجود هنوز از v1.4 استفاده می‌کنند. در طول کل دوره از ارسال تا انتشار، سرور باید هر دو نسخه را همزمان پشتیبانی کند تا بررسی‌کنندگان اپل بتوانند v1.5 را تست کنند و کاربران موجود بدون وقفه به استفاده از v1.4 ادامه دهند.

در توسعه اپلیکیشن، یک «نقطه پایانی» به سادگی جایی است که اپلیکیشن درخواست‌های خود را به سرور می‌فرستد — به‌نوعی شبیه یک باجه خاص در شهرداری. یک باجه ثبت ازدواج‌ها را مدیریت می‌کند، دیگری سوابق ساکنین را و دیگری پاسپورت‌ها را. اپلیکیشن‌ها به همین روش کار می‌کنند: هر نقطه پایانی یک پنجره اختصاصی است که سرور یک نوع خاص از درخواست مانند ورود به سیستم، ایجاد پروژه، ویرایش هزینه، درخواست دوستی و غیره را قبول می‌کند. وقتی Splync v1.4 یک درخواست می‌فرستد، به «پنجره» قدیمی می‌رود که فرمت قدیمی را می‌فهمد. Splync v1.5 درخواست خود را به «پنجره» جدیدی می‌فرستد که داده‌های نسبت را می‌فهمد. اگر سرور پنجره قدیمی را خیلی زود ببندد، کاربران v1.4 جایی برای «ارسال» داده‌های خود نخواهند داشت. به همین دلیل، در طول یک به‌روزرسانی، سرور باید هر دو پنجره را باز نگه دارد — هر دو نقطه پایانی — تا همه کاربران به نسخه جدیدتر به‌سلامت منتقل شوند. صادقانه بگویم، مدیریت همزمان این دو پنجره مثل فکر کردن در یک بُعد اضافی بود.

Splync v1.5 می‌تواند نسبت‌ها را بر اساس پروژه و دسته تنظیم کند، اما هنوز بر اساس هر هزینه نمی‌تواند. برای پشتیبانی از نسبت‌های بر اساس هزینه، به یک لایه ساختاری دیگر نیاز داریم — در واقع یک بازنویسی عمیق‌تر از چگونگی ذخیره و محاسبه سهم هر هزینه. همچنین باید مراقب باشیم که رابط کاربری اپلیکیشن به‌طور ناگهانی پیچیده نشود فقط برای افزودن قدرت بیشتر. این ارتقایی بزرگتر از چیزی است که به نظر می‌رسد. لطفاً به ما کمی زمان بیشتر بدهید تا به آنجا برسیم. در چشم‌انداز ماست — و به آن خواهیم رسید. تا آن زمان، بگذارید ببینیم چگونه نسبت‌های جدید پروژه و دسته‌بندی هزینه‌های مشترک را بسیار انعطاف‌پذیرتر می‌کنند.