Splync v1.9 מאפשר לקבוע יחס שיתוף מותאם אישית לכל הוצאה

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

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

הפריצה הגיעה בסופו של דבר מהפיכת המבנה על פיו. במקום לעשות "פרויקט → קטגוריה → הוצאה" ולהחליף כל שכבה עם הבאה, מדוע לא לחשוב בכיוון ההפוך? חלוקה להוצאה → חלוקה לקטגוריה → חלוקה לפרויקט. סדר זה משקף איך אנשים אמיתיים חושבים: אם להוצאה מסוימת יש כללים משלה, היא פשוט צריכה לעקוב אחריהם. אם לא, התבנית של הקטגוריה הגיונית. אם גם זה לא עובד, נופלים חזרה לברירת המחדל של הפרויקט. אין יותר מדרגות של החלפות — רק היררכיה נקייה של עדיפות. ברגע שראיתי את המבנה כך, הערפל של היער הפרקטלי התפזר מיד. מסלול היישום הפך ברור: "כל הוצאה נבדקת אם יש לה חלוקה מותאמת אישית. אם יש, משתמשים בה. אם לא, בודקים חלוקה לפי קטגוריה. אם לא, משתמשים בברירת המחדל של הפרויקט."

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

Splync v1.9 נולד מהרגע הזה של בהירות. חזרתי הביתה, סיימתי לחבר את נקודות הקצה החדשות, הכנתי את הלוגיקה החדשה בשרת, סידרתי את הממשקים הקשורים, שלחתי את v1.9 ל-Apple ובסופו של דבר נרדמתי. הבדיקה הסתיימה מוקדם מהרגיל. כשקמתי, Splync v1.9 כבר אושר ושוחרר אוטומטית ב-App Store. מהגרסה הזו ואילך, החלוקה הופכת להרבה יותר גמישה. אם אתה מטייל עם ג'ון וקייט, אתה יכול להתחלק בהוצאות בסיסיות באופן שווה בין השלושה. אך עבור אוכל, ייתכן שתרצה לעבור ליחס של "25% : 50% : 25%" כי ג'ון אוכל פי שניים בדרך כלל. ואם ג'ון מדלג על ארוחת ערב אחת — נאמר, במסעדת צדפים — תוכל להגדיר את הארוחה הספציפית הזו ל-"50% : 0% : 50%" כדי שהוא לא ישלם על מה שלא אכל. עם v1.9, Splync תומך כעת בנתחים לפי פרויקט, לפי קטגוריה ולפי הוצאה בלוגיקה מאוחדת. היסודות יציבים וחישוביים. האתגר הבא הוא הממשק: יש אפליקציות חלוקה אחרות שמציעות דרכים חלקות ומסוגננות יותר להתאים את היחסים הללו. ל-Splync יש כעת את החוזק אחורי לתמוך בשיפורים כאלה. נעבוד עליהם אחד אחד.