Splync v1.9 può impostare percentuali di condivisione personalizzate per ogni spesa

Circa un mese e mezzo dopo il rilascio di Splync v1.5 — l'aggiornamento che consentiva finalmente percentuali di ripartizione personalizzate per progetto e categoria — è arrivata una nuova ondata di feedback. L'aggiornamento v1.5 richiedeva importanti modifiche lato server, quindi a quel tempo credevo che la granularità fosse "abbastanza buona" per la maggior parte dei casi d'uso. Poi alcuni nuovi utenti hanno posto una domanda semplice e ragionevole: "Possiamo impostare percentuali di condivisione personalizzate per ogni singola spesa?" Il loro progetto di viaggio aveva momenti in cui solo due membri dovevano dividere un costo specifico e altri momenti in cui tutti e tre volevano condividere una spesa. Con Splync v1.8, la risposta era purtroppo no. Ho spiegato che potevano creare categorie aggiuntive con percentuali personalizzate adatte a quei casi specifici — una soluzione temporanea, non una vera soluzione.

Era un po' opprimente ricordare quanti sforzi fossero stati necessari per la v1.5. Prima dovevo consentire ai progetti di avere le loro percentuali di ripartizione. Poi anche le categorie necessitavano delle loro percentuali personalizzate. A quel punto pensavo di aver coperto tutto — raccogliendo ogni frutto da ogni ramo. Ma lavorare su percentuali per spesa era diverso. Sembrava che ogni volta che raccoglievo un frutto, un nuovo albero germogliasse proprio lì. Non una foresta frattale infinita, ma una chiara struttura a due piani: un livello che dava origine al successivo. Nella logica della v1.5, una spesa ereditava prima la percentuale del progetto. Se la sua categoria aveva percentuali personalizzate, queste sovrascrivevano i valori del progetto. Così quando aggiungevo percentuali per spesa, mi trovavo a cercare di aggiungere un'altra sovrascrittura sopra quella sovrascrittura. La struttura diventava una scala di sovrascritture — tecnicamente corretta, ma mentalmente confusa. Era difficile giustificare la costruzione di un altro strato di logica rattoppata.

La svolta è arrivata invertendo la struttura. Invece di fare "progetto → categoria → spesa" e sovrascrivere ogni livello con il successivo, perché non pensare nella direzione opposta? Condivisioni per spesa → condivisioni per categoria → condivisioni per progetto. Questo ordine riflette come le persone reali potrebbero pensare: se una spesa specifica ha le sue regole, dovrebbe semplicemente seguirle. Altrimenti, il modello della categoria ha senso. Se anche questo fallisce, si ricorre al valore predefinito del progetto. Niente più scala di sovrascritture — solo una gerarchia di priorità chiara. Una volta vista la struttura in questo modo, la nebbia della pseudo-foresta frattale si è dissolta immediatamente. Il percorso di implementazione è diventato evidente: "Ogni spesa viene controllata per condivisioni personalizzate per spesa. Se presenti, usarle. Se no, controllare le condivisioni per categoria. Se no, usare il valore predefinito del progetto."

La nuova logica sembrava semplice, prevedibile e matematicamente solida. Per supportare questo sistema di priorità, abbiamo aggiunto una tabella MariaDB dedicata per le ripartizioni per spesa, in qualche modo rispecchiando la tabella per le ripartizioni per categoria. Anche la tabella dei dettagli delle spese aveva bisogno di espansione, proprio come la tabella dei dettagli delle categorie nel v1.5. Una volta chiara la struttura "a due piani" sottostante, il resto è stato solo programmazione attenta — sia nell'app che sul server. Tuttavia, il percorso sembrava rischioso in certi punti, come camminare in una foresta oscura senza mappa. Ho voluto schiarirmi le idee e sono uscito. L'aria era fresca e pulita. Mentre camminavo per i miei quartieri, vedevo il Monte Fuji in lontananza, cristallino sotto un cielo perfettamente blu. Era a quasi 100 km di distanza, eppure sembrava abbastanza vicino da poterlo toccare. Quel momento sembrava un promemoria: anche se penso di camminare in una foresta, sto in realtà camminando sotto il cielo aperto.

Splync v1.9 è nato da quel momento di chiarezza. Sono tornato a casa, ho finito di configurare i nuovi endpoint, preparato la nuova logica del server, organizzato le interfacce correlate, inviato la v1.9 ad Apple e infine mi sono addormentato. La revisione è terminata prima del solito. Quando mi sono svegliato, Splync v1.9 era già stato approvato e rilasciato automaticamente su App Store. Da questa versione in poi, la ripartizione diventa molto più flessibile. Se viaggi con John e Kate, puoi dividere le spese di base equamente tra voi tre. Ma per il cibo, potresti passare a una ripartizione "25% : 50% : 25%" perché John solitamente mangia il doppio. E se John salta una cena — diciamo, in un ristorante di ostriche — puoi impostare quel pasto specifico su "50% : 0% : 50%" così non paga per ciò che non ha mangiato. Con la v1.9, Splync ora supporta percentuali per progetto, per categoria e per spesa in una logica unificata. Le fondamenta sono stabili e matematicamente solide. La prossima sfida è l'interfaccia: alcune altre app di ripartizione offrono modi più fluidi e stilosi per regolare quelle percentuali. Splync ha ora la forza del backend per supportare tali miglioramenti. Lavoreremo su di essi uno dopo l'altro.