Splync v1.5 — Nisbah Pembahagian Boleh Diubahsuai Per Projek dan Kategori

Pada 16 September 2025, Splync v1.5 dilancarkan — hanya empat hari setelah perkahwinan antarabangsa kami akhirnya diterima oleh bandar. Sebelum kemas kini ini, Splync tidak dapat menyesuaikan nisbah pembahagian; setiap perbelanjaan dibahagi secara rata secara lalai. Dengan v1.5, pengguna kini boleh menetapkan nisbah tersuai untuk setiap projek dan kategori. Perubahan ini membolehkan pasangan dan rakan membahagikan kos bersama dengan cara yang lebih mencerminkan kehidupan sebenar mereka, bukan sekadar 50:50 yang mudah. Anda boleh memulakan projek akaun baharu dengan pembahagian 60:40 untuk perbelanjaan harian mulai Oktober, sambil mengekalkan sewa apartmen anda pada 50:50 jika itu adil untuk anda berdua. Dan jika barang runcit lebih seimbang pada 70:30 sementara bil utiliti lebih sesuai pada 62:38, anda kini boleh menetapkan nisbah tersebut secara berasingan — kategori demi kategori — dalam projek yang sama.

Perubahan paling ketara dalam v1.5 ialah bahagian Ahli & Bahagian Lalai yang baharu, di mana anda boleh menambah ahli projek dan menetapkan bahagian lalai untuk setiap orang. Jika projek mempunyai dua ahli, nisbah boleh jadi 50:50, 40:60, atau apa sahaja yang dirasakan sesuai. Dengan tiga ahli, ia boleh menjadi 33.33:33.33:33.34, 50:25:25, atau sebarang kombinasi pilihan anda. Ini menjadi bahagian lalai projek. Di bawahnya, anda boleh menatal ke bawah untuk menyesuaikan bahagian setiap kategori jika anda mahu ia berbeza daripada lalai projek. Apabila anda menetapkan nisbah tersuai kepada kategori, tanda nisbah birunya bertukar menjadi oren — petunjuk visual kecil bahawa kategori itu menggunakan peraturannya sendiri dan bukan peraturan seluruh projek. Walaupun perubahan ini menambah lebih banyak fleksibiliti kepada tetapan projek, ia juga menjadikan paparan cipta/edit projek sedikit lebih kompleks. Untuk membantu perkara ini, saya menambahkan butang maklumat pada setiap bahagian supaya anda boleh mengetiknya untuk melihat pembantu soalan dan jawapan kecil.

Melaksanakan perubahan ini lebih rumit daripada yang dijangka. Splync sentiasa menganggap dunia 50:50 yang bersih — satu nombor, digunakan di mana-mana, dan kira-kira selesai. Setelah saya memutuskan untuk menyokong nisbah tersuai, seluruh struktur dalaman perlu difikirkan semula. Projek tidak boleh lagi bergantung pada peratusan berkongsi tunggal. Setiap kategori memerlukan nisbahnya sendiri, dan setiap perbelanjaan perlu merujuk kepada lalai peringkat projek dan penggantian kategori. Untuk menjayakan ini, saya menulis semula logik pengiraan dari asas. Setiap perbelanjaan kini membawa pokok keputusan kecil: "Adakah kategori ini mempunyai nisbahnya sendiri? Jika ya, gunakannya. Jika tidak, kembali kepada nisbah projek." Kedengaran mudah apabila dijelaskan, tetapi memastikan model data tetap konsisten di seluruh aplikasi — paparan iOS, backend FastAPI, dan skema MariaDB — memerlukan lebih banyak penalaan teliti daripada yang dijangka.

Sebarang kemas kini yang melibatkan bahagian pelayan perlu ditangani dengan sangat berhati-hati. Jika anda tersilap mengubah kod pelayan yang sedia ada, pengguna yang masih menggunakan v1.4 akan segera mengalami pepijat atau ralat sistem. Sebagai contoh, program pelayan untuk v1.5 mengharapkan tetapan projek merangkumi data nisbah, tetapi aplikasi v1.4 menghantar tetapan projek tanpa sebarang nisbah. Saat dua versi itu cuba berkomunikasi, permintaan gagal — hanya kerana mereka bercakap dalam "bahasa" yang sedikit berbeza. Pembangun tentu boleh membuat perubahan dengan selamat dalam persekitaran ujian. Bahagian sukar bermula selepas menyerahkan versi baru untuk ulasan Apple semasa pengguna sedia ada masih menggunakan v1.4. Sepanjang tempoh dari penyerahan hingga pelepasan, pelayan mesti menyokong kedua-dua versi pada masa yang sama supaya penilai Apple boleh menguji v1.5 dan pengguna sedia ada boleh terus menggunakan v1.4 tanpa gangguan.

Dalam pembangunan aplikasi, "titik akhir" hanyalah tempat aplikasi menghantar permintaannya di pelayan — seperti kaunter tertentu di balai kota. Satu kaunter mengendalikan pendaftaran perkahwinan, satu lagi mengendalikan rekod penduduk, dan satu lagi mengendalikan pasport. Aplikasi berfungsi dengan cara yang sama: setiap titik akhir adalah tetingkap khusus di mana pelayan menerima jenis permintaan tertentu seperti log masuk, pembuatan projek, penyuntingan perbelanjaan, permintaan rakan, dan lain-lain. Apabila Splync v1.4 menghantar permintaan, ia pergi ke tetingkap "lama" yang memahami format lama. Splync v1.5 menghantar permintaannya ke tetingkap "baru" yang memahami data nisbah. Jika pelayan menutup tetingkap lama terlalu awal, pengguna v1.4 tidak akan ada tempat untuk "menghantar" data mereka. Itulah sebabnya, semasa kemas kini, pelayan perlu memastikan kedua-dua tetingkap terbuka — kedua-dua titik akhir — sehingga semua pengguna telah beralih dengan selamat ke versi yang lebih baru. Sejujurnya, menguruskan kedua-dua tetingkap pada masa yang sama terasa seperti berfikir dalam dimensi tambahan.

Splync v1.5 dapat menyesuaikan pembahagian per projek dan per kategori, tetapi belum lagi per perbelanjaan. Untuk menyokong nisbah per perbelanjaan, kami memerlukan lapisan struktur lain — pada dasarnya penulisan semula yang lebih mendalam tentang bagaimana setiap perbelanjaan menyimpan dan mengira bahagiannya. Kami juga perlu berhati-hati agar tidak menjadikan antara muka aplikasi tiba-tiba rumit semata-mata untuk menambah lebih banyak kuasa. Ia adalah peningkatan yang lebih besar daripada yang didengar. Harap beri kami sedikit masa lagi untuk sampai ke sana. Ia sudah dalam perancangan kami — dan kami akan mencapainya. Sehingga itu, mari kita lihat bagaimana nisbah baru per projek dan per kategori sudah menjadikan perbelanjaan bersama lebih fleksibel.