Splync v1.5 — نسب تقسيم مخصصة لكل مشروع وفئة

في 16 سبتمبر 2025، تم إصدار Splync v1.5 — بعد أربعة أيام فقط من موافقة المدينة أخيرًا على زواجنا الدولي. قبل هذا التحديث، لم يكن بإمكان Splync تخصيص نسب التقسيم على الإطلاق؛ فقد كانت كل النفقات تُقسم بالتساوي بشكل افتراضي. مع الإصدار v1.5، يمكن للمستخدمين الآن تعيين نسب مخصصة لكل مشروع ولكل فئة. يتيح هذا التغيير للأزواج والأصدقاء تقسيم تكاليفهم المشتركة بطرق تعكس حياتهم الواقعية بشكل أفضل، وليس مجرد تقسيم بسيط 50:50. يمكنك بدء مشروع محاسبي جديد بنسبة تقسيم 60:40 للنفقات اليومية اعتبارًا من أكتوبر، مع الاحتفاظ بإيجار الشقة بنسبة 50:50 إذا كان ذلك يبدو عادلاً لكما. وإذا كانت محلات البقالة أكثر توازنًا عند 70:30 في حين أن المرافق تبدو أفضل عند 62:38، يمكنك الآن تعيين هذه النسب بشكل منفصل — فئة بفئة — داخل نفس المشروع.

التغيير الأكثر وضوحًا في الإصدار v1.5 هو قسم الأعضاء والحصص الافتراضية الجديد، حيث يمكنك إضافة أعضاء المشروع وتعيين حصة افتراضية لكل شخص. إذا كان للمشروع عضوين، يمكن أن تكون النسبة 50:50، 40:60، أو أي شيء يبدو مناسبًا. مع ثلاثة أعضاء، يمكن أن تكون 33.33:33.33:33.34 أو 50:25:25 أو أي تركيبة تفضلها. يصبح هذا هو التقسيم الافتراضي للمشروع. يمكنك التمرير لأسفل لضبط حصة كل فئة إذا كنت تفضل أن تختلف عن القيم الافتراضية للمشروع. عندما تعين نسبة مخصصة لفئة معينة، يتحول مؤشر النسبة الأزرق إلى اللون البرتقالي — وهو دلالة بصرية صغيرة على أن الفئة تستخدم قاعدة خاصة بها بدلاً من القاعدة العامة للمشروع. بينما يضيف هذا التغيير مرونة أكبر لإعدادات المشروع، فإنه يجعل عرض إنشاء/تعديل المشروع أكثر تعقيدًا بعض الشيء. للمساعدة في هذا، أضفت أزرار معلومات لكل قسم بحيث يمكنك النقر عليها لرؤية مساعدات صغيرة للأسئلة والأجوبة.

كان تنفيذ هذا التغيير أكثر تعقيدًا مما توقعت. كان Splync دائمًا يفترض عالمًا نظيفًا بنسبة 50:50 — رقم واحد مطبق في كل مكان، ويتم الحساب. بمجرد أن قررت دعم النسب المخصصة، كان يجب إعادة التفكير في البنية الداخلية بالكامل. لم يعد بإمكان المشروع الاعتماد على نسبة مشتركة واحدة. كانت كل فئة بحاجة إلى نسبتها الخاصة، وكان يجب أن تشير كل نفقة إلى النسبة الافتراضية للمشروع وتجاوز الفئة. لجعل هذا يعمل، قمت بإعادة كتابة منطق الحساب من الأساس. تحمل كل نفقة الآن شجرة قرارات صغيرة: "هل لهذه الفئة نسبتها الخاصة؟ إذا نعم، استخدمها. إذا لا، ارجع إلى نسبة المشروع." يبدو الأمر بسيطًا عندما تشرحه، ولكن الحفاظ على نموذج البيانات متسقًا عبر التطبيق — واجهات iOS، الواجهة الخلفية لـ FastAPI، ومخططات MariaDB — تطلب ضبطًا أكثر دقة مما توقعت.

أي تحديث يتضمن الجانب الخادمي يجب التعامل معه بحذر شديد. إذا قمت بتعديل شفرة الخادم الحالية عن طريق الخطأ، فإن المستخدمين الذين لا يزالون على الإصدار v1.4 سيتعرضون فورًا لأخطاء أو مشاكل في النظام. على سبيل المثال، يتوقع برنامج الخادم للإصدار v1.5 أن تتضمن إعدادات المشروع بيانات النسبة، لكن تطبيق v1.4 يرسل إعدادات المشروع بدون أي نسب على الإطلاق. في اللحظة التي تحاول فيها هاتان النسختان التحدث معًا، يفشل الطلب — ببساطة لأنها تتحدث "لغات" مختلفة قليلاً. يمكن للمطورين بالطبع إجراء تغييرات بأمان في بيئة اختبار. الجزء الصعب يبدأ بعد تقديم إصدار جديد لمراجعة Apple بينما لا يزال المستخدمون الحاليون على الإصدار v1.4. خلال الفترة من التقديم إلى الإصدار، يجب على الخادم دعم كلتا النسختين في نفس الوقت حتى يتمكن مراجعو Apple من اختبار الإصدار v1.5 ويستمر المستخدمون الحاليون في استخدام الإصدار v1.4 دون انقطاع.

في تطوير التطبيقات، "النقطة النهائية" هي ببساطة المكان الذي يرسل فيه التطبيق طلباته على الخادم — مثل عداد محدد في قاعة المدينة. يتعامل عداد واحد مع تسجيل الزواج، وآخر يتعامل مع سجلات الإقامة، وآخر مع جوازات السفر. تعمل التطبيقات بنفس الطريقة: كل نقطة نهائية هي نافذة مخصصة حيث يقبل الخادم نوعًا محددًا من الطلبات مثل تسجيل الدخول، إنشاء مشروع، تحرير النفقات، طلب الصداقة، إلخ. عندما يرسل Splync v1.4 طلبًا، يذهب إلى "النافذة القديمة" التي تفهم التنسيق الأقدم. يرسل Splync v1.5 طلبه إلى "نافذة جديدة" تفهم بيانات النسبة. إذا أغلق الخادم النافذة القديمة مبكرًا، فلن يكون لدى مستخدمي الإصدار v1.4 مكان لتقديم بياناتهم. لهذا السبب، أثناء التحديث، يحتاج الخادم إلى إبقاء كلتا النوافذ مفتوحة — كلتا النقاط النهائية — حتى ينتقل كل مستخدم بأمان إلى النسخة الأحدث. لنكون صادقين، إدارة هاتين النافذتين في نفس الوقت بدا وكأننا نفكر في بعد إضافي.

يمكن لـ Splync v1.5 تخصيص التقسيم لكل مشروع ولكل فئة، ولكن ليس بعد لكل نفقة. لدعم نسب النفقات الفردية، نحتاج إلى طبقة هيكلية أخرى — في الأساس إعادة كتابة أعمق لكيفية تخزين وحساب كل نفقة لحصصها. علينا أيضًا أن نكون حذرين حتى لا نجعل واجهة التطبيق معقدة فجأة فقط لأجل إضافة مزيد من القوة. إنه ترقية أكبر مما يبدو. أرجو أن تمنحنا بعض الوقت للوصول إلى هناك. إنه على أفقنا — وسنصل إليه. حتى ذلك الحين، دعونا نستكشف كيف أن النسب الجديدة لكل مشروع وفئة تجعل النفقات المشتركة أكثر مرونة.