Splync v1.9 Boleh Tetapkan Nisbah Perkongsian Tersuai untuk Setiap Perbelanjaan

Kira-kira satu setengah bulan selepas pelancaran Splync v1.5 — kemas kini yang akhirnya membenarkan nisbah pecahan tersuai per projek dan per kategori — gelombang maklum balas baru tiba. Kemas kini v1.5 memerlukan perubahan besar pada pelayan, jadi pada masa itu, saya percaya kehalusan tersebut sudah "cukup baik" untuk kebanyakan kes penggunaan. Kemudian beberapa pengguna baru bertanya soalan mudah dan munasabah: "Bolehkah kami menetapkan nisbah perkongsian tersuai untuk setiap perbelanjaan individu?" Projek perjalanan mereka mempunyai situasi di mana hanya dua ahli perlu berkongsi kos tertentu, dan masa lain ketiga-tiganya ingin berkongsi sesuatu. Di bawah Splync v1.8, jawapannya malangnya tidak. Saya menjelaskan bahawa mereka boleh mencipta kategori tambahan dengan nisbah tersuai yang disesuaikan untuk kes-kes khusus tersebut — penyelesaian sementara, bukan penyelesaian sebenar.

Ia terasa agak menakutkan untuk mengingati berapa banyak kerja yang dimasukkan ke dalam v1.5. Mula-mula saya harus membenarkan projek mempunyai nisbah pecahan mereka sendiri. Kemudian kategori juga memerlukan nisbah tersuai mereka sendiri. Pada ketika itu saya fikir saya telah meliputi keseluruhan pokok — mengumpul setiap buah dari setiap dahan. Tetapi bekerja pada nisbah perbelanjaan adalah berbeza. Ia terasa seolah-olah setiap kali saya mengambil buah, pokok baru tumbuh dari tempat itu. Bukan hutan fraktal yang tidak terhingga, tetapi struktur dua tingkat yang jelas: satu lapisan melahirkan yang seterusnya. Dalam logik v1.5, perbelanjaan pertama kali mewarisi nisbah projek. Jika kategorinya mempunyai nisbah tersuai, ia akan menimpa nilai projek. Jadi apabila menambah nisbah perbelanjaan, saya mendapati diri saya cuba menambah satu lagi timpa di atas itu. Struktur itu menjadi tangga timpa — secara teknikal betul, tetapi secara mental berserabut. Sukar untuk membenarkan membina satu lagi lapisan logik penyelesaian masalah.

Penerangan akhirnya datang dengan membalikkan struktur itu. Daripada melakukan "projek → kategori → perbelanjaan" dan menimpa setiap lapisan dengan yang berikutnya, mengapa tidak berfikir dalam arah yang bertentangan? Bahagian perbelanjaan → bahagian per kategori → bahagian per projek. Susunan itu mencerminkan bagaimana orang sebenar mungkin berfikir: jika perbelanjaan tertentu mempunyai peraturannya sendiri, ia harus mengikutinya. Jika tidak, corak kategori masuk akal. Jika itu pun gagal, kembali ke lalai projek. Tiada lagi tangga timpa — hanya hierarki keutamaan yang bersih. Sebaik sahaja saya melihat struktur ini, kabus hutan pseudo-fraktal segera hilang. Jalan pelaksanaan menjadi jelas: "Setiap perbelanjaan diperiksa untuk bahagian tersuai per perbelanjaan. Jika ada, gunakan ia. Jika tidak, periksa bahagian per kategori. Jika tidak, gunakan lalai projek."

Logik baru ini terasa mudah, boleh diramalkan, dan secara matematik tepat. Untuk menyokong sistem keutamaan ini, kami menambah jadual MariaDB yang dikhususkan untuk pecahan perbelanjaan, seolah-olah mencerminkan jadual untuk pecahan per kategori. Jadual butiran perbelanjaan juga memerlukan pengembangan, sama seperti jadual butiran kategori kembali dalam v1.5. Setelah reka bentuk "dua tingkat" yang mendasari itu menjadi jelas, selebihnya adalah pengkodan yang teliti — baik dalam aplikasi mahupun di pelayan. Namun, jalannya terasa berisiko di beberapa tempat, seperti berjalan melalui hutan gelap tanpa peta. Saya ingin menenangkan fikiran dan melangkah keluar. Udara terasa tajam dan bersih. Semasa berjalan melalui kawasan kejiranan saya, saya melihat Gunung Fuji menjulang di kejauhan, biru jernih di bawah langit biru sempurna. Ia hampir 100 km jauhnya, tetapi kelihatan cukup dekat untuk disentuh. Saat itu terasa seperti peringatan: walaupun saya fikir saya sedang berjalan di dalam hutan, sebenarnya saya sedang berjalan di bawah langit terbuka.

Splync v1.9 lahir dari saat kejelasan itu. Saya pulang ke rumah, menyelesaikan penyambungan titik akhir baru, menyediakan logik pelayan baru, menyusun antara muka yang berkaitan, menyerahkan v1.9 kepada Apple, dan akhirnya tertidur. Semakan selesai lebih awal daripada biasa. Apabila saya bangun, Splync v1.9 telah pun diluluskan dan dikeluarkan secara automatik di App Store. Mulai versi ini, pemisahan menjadi lebih fleksibel. Jika anda melancong dengan John dan Kate, anda boleh berkongsi perbelanjaan asas sama rata antara kamu bertiga. Tetapi untuk makanan, anda mungkin beralih kepada pecahan "25% : 50% : 25%" kerana John biasanya makan dua kali lebih banyak. Dan jika John tidak hadir untuk satu makan malam—katakan, di restoran tiram—anda boleh menetapkan hidangan tertentu itu kepada "50% : 0% : 50%" supaya dia tidak membayar untuk apa yang tidak dimakannya. Dengan v1.9, Splync kini menyokong nisbah per projek, per kategori, dan per perbelanjaan dalam logik bersatu. Asasnya stabil dan tepat secara matematik. Cabaran seterusnya adalah antara muka: beberapa aplikasi perpecahan lain menawarkan cara yang lebih lancar dan bergaya untuk melaraskan nisbah tersebut. Splync kini mempunyai kekuatan backend untuk menyokong penambahbaikan sedemikian. Kami akan mengusahakannya satu demi satu.