Splync v1.9 peut définir des ratios de partage personnalisés pour chaque dépense

Environ un mois et demi après la sortie de Splync v1.5 — la mise à jour qui a enfin permis des ratios de partage personnalisés par projet et par catégorie — une nouvelle vague de retours est arrivée. La v1.5 a nécessité de lourdes modifications côté serveur, donc à l'époque, je pensais que la granularité était « suffisante » pour la plupart des cas d'utilisation. Puis quelques nouveaux utilisateurs ont posé une question simple et très raisonnable : « Peut-on définir des ratios de partage personnalisés pour chaque dépense ? » Leur projet de voyage comportait des moments où seuls deux membres devaient partager un coût spécifique, et d'autres moments où les trois voulaient partager quelque chose. Sous Splync v1.8, la réponse était malheureusement non. J'ai expliqué qu'ils pouvaient créer des catégories supplémentaires avec des ratios personnalisés adaptés à ces cas spécifiques — une solution de contournement, pas une véritable solution.

C'était un peu écrasant de se rappeler combien de travail a été nécessaire pour la v1.5. D'abord, il fallait que les projets aient leurs propres ratios de partage. Ensuite, les catégories avaient aussi besoin de leurs propres ratios personnalisés. À ce moment-là, je pensais avoir couvert tout l'arbre — récoltant chaque fruit de chaque branche. Mais travailler sur les ratios par dépense était différent. C'était comme si chaque fois que je cueillais un fruit, un nouvel arbre poussait à cet endroit précis. Pas une forêt fractale infinie, mais une structure à deux étages claire : une couche donnant naissance à la suivante. Dans la logique de la v1.5, une dépense héritait d'abord du ratio du projet. Si sa catégorie avait des ratios personnalisés, ceux-ci remplaçaient les valeurs du projet. Donc, en ajoutant des ratios par dépense, je me suis retrouvé à essayer d'ajouter une autre substitution par-dessus celle-ci. La structure est devenue un escalier de remplacements — techniquement correct, mais mentalement confus. Il était difficile de justifier la construction d'une autre couche de logique de patchwork.

La percée est finalement venue en renversant la structure. Au lieu de faire "projet → catégorie → dépense" et de remplacer chaque couche par la suivante, pourquoi ne pas penser à l'inverse ? Partages par dépense → partages par catégorie → partages par projet. Cette ordre reflète comment les gens pensent réellement : si une dépense spécifique a ses propres règles, elle devrait simplement les suivre. Sinon, le modèle de la catégorie a du sens. Si cela échoue aussi, revenez au défaut du projet. Plus d'escalier de substituts — juste une hiérarchie claire de priorité. Une fois que j'ai vu la structure de cette manière, le brouillard de la pseudo-forêt fractale s'est instantanément dissipé. Le chemin de mise en œuvre est devenu évident : "Chaque dépense est vérifiée pour des partages personnalisés par dépense. Si présent, utilisez-les. Sinon, vérifiez les partages par catégorie. Sinon, utilisez le défaut du projet."

La nouvelle logique semblait simple, prévisible et mathématiquement solide. Pour soutenir ce système de priorités, nous avons ajouté une table MariaDB dédiée pour les partages par dépense, un peu comme la table pour les partages par catégorie. La table des détails des dépenses avait également besoin d'être étendue, tout comme celle des détails des catégories l'a été lors de la v1.5. Une fois que le design "à deux étages" sous-jacent est devenu clair, le reste n'était qu'un codage minutieux — à la fois dans l'application et sur le serveur. Pourtant, le chemin semblait risqué par endroits, comme marcher dans une forêt sombre sans carte. Je voulais me vider la tête et suis sorti. L'air était vif et pur. En me promenant dans mon quartier, j'ai vu le mont Fuji se dresser au loin, d'un bleu cristallin sous un ciel parfaitement bleu. Il était à presque 100 km, mais il paraissait assez proche pour être touché. Ce moment ressemblait à un rappel : même si je pense marcher dans une forêt, je marche en réalité sous un ciel ouvert.

Splync v1.9 est né de ce moment de clarté. Je suis rentré chez moi, ai terminé le câblage des nouveaux points de terminaison, préparé la nouvelle logique serveur, organisé les interfaces associées, soumis v1.9 à Apple, et finalement je me suis endormi. La révision s'est terminée plus tôt que d'habitude. Quand je me suis réveillé, Splync v1.9 avait déjà été approuvé et automatiquement publié sur l'App Store. À partir de cette version, le partage devient beaucoup plus flexible. Si vous voyagez avec John et Kate, vous pouvez partager les dépenses de base équitablement entre vous trois. Mais pour la nourriture, vous pourriez opter pour un partage "25% : 50% : 25%" parce que John mange généralement deux fois plus. Et si John saute un dîner — disons, dans un restaurant d'huîtres — vous pouvez régler ce repas spécifique à "50% : 0% : 50%" pour qu'il ne paie pas ce qu'il n'a pas mangé. Avec la v1.9, Splync prend désormais en charge les ratios par projet, par catégorie et par dépense dans une logique unifiée. Les fondations sont stables et mathématiquement solides. Le prochain défi est l'interface : certaines autres applications de partage offrent des moyens plus fluides et plus élégants pour ajuster ces ratios. Splync a désormais la force en coulisse pour soutenir ces améliorations. Nous y travaillerons une à une.