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, ה-backend של FastAPI, ו-MariaDB schemas — דרש כיוון זהיר יותר ממה שציפיתי.

כל עדכון שנוגע לצד השרת צריך להתבצע בזהירות רבה. אם תשנה בטעות קוד שרת קיים, משתמשים שעדיין על v1.4 ייתקלו מיד בבאגים או בשגיאות מערכת. למשל, תוכנת השרת עבור v1.5 מצפה שהגדרות הפרויקט יכללו נתוני יחס, אך האפליקציה של v1.4 שולחת הגדרות פרויקט ללא יחסים כלל. ברגע ששתי הגרסאות האלו ינסו לתקשר, הבקשה תיכשל — פשוט בגלל שהן מדברות "שפות" מעט שונות. מפתחים יכולים, כמובן, לבצע שינויים בבטחה בסביבת בדיקה. החלק המאתגר מתחיל לאחר הגשת גרסה חדשה לסקירה של אפל בזמן שמשתמשים קיימים עדיין על v1.4. במהלך כל התקופה מהגשה לשחרור, השרת חייב לתמוך בשתי הגרסאות בו זמנית כך שסוקרי אפל יוכלו לבדוק את v1.5 ומשתמשים קיימים יוכלו להמשיך להשתמש ב-v1.4 ללא הפרעות.

בפיתוח אפליקציות, "נקודת קצה" היא פשוט המקום שבו האפליקציה שולחת את הבקשות שלה על השרת — קצת כמו דלפק ספציפי בעירייה. דלפק אחד מטפל ברישום נישואין, אחר מטפל ברישומי תושבים, ואחר מטפל בדרכונים. אפליקציות פועלות באותו אופן: כל נקודת קצה היא חלון ייעודי שבו השרת מקבל סוג מסוים של בקשה כמו התחברות, יצירת פרויקט, עריכת הוצאה, בקשת חברות וכו'. כש-Splync v1.4 שולחת בקשה, היא מגיעה לחלון "הישן" שמבין את הפורמט הישן יותר. Splync v1.5 שולחת את הבקשה שלה לחלון "החדש" שמבין נתוני יחס. אם השרת היה סוגר את החלון הישן מוקדם מדי, למשתמשי v1.4 לא היה מקום ל"הגיש" את הנתונים שלהם. זו הסיבה שבמהלך עדכון, השרת צריך להחזיק את שני החלונות פתוחים — שתי נקודות הקצה — עד שכל משתמש יעבור בבטחה לגרסה החדשה יותר. בכנות, ניהול שני החלונות בו זמנית הרגיש כמו לחשוב בממד נוסף.

Splync v1.5 יכולה להתאים חלוקות לפי פרויקט וקטגוריה, אך עדיין לא לפי הוצאה. כדי לתמוך ביחסי הוצאה, אנחנו צריכים שכבה מבנית נוספת — למעשה, כתיבה מחדש מעמיקה יותר של איך כל הוצאה מאחסנת ומחשבת את החלקים שלה. אנחנו גם צריכים להיזהר שלא להפוך את הממשק של האפליקציה למסובך פתאום רק לשם הוספת יותר כוח. זה שדרוג גדול יותר ממה שזה נשמע. בבקשה תנו לנו עוד קצת זמן להגיע לשם. זה באופק שלנו — ונגיע לשם. עד אז, בואו נחקור איך היחסים החדשים לפי פרויקט וקטגוריה כבר הופכים את ההוצאות המשותפות לגמישות הרבה יותר.