Splync v1.5 — Proje ve Kategoriye Göre Özelleştirilebilir Bölme Oranları

Splync v1.5, 16 Eylül 2025'te yayınlandı — uluslararası evliliğimizin şehir tarafından kabul edilmesinden sadece dört gün sonra. Bu güncellemeye kadar, Splync bölme oranlarını özelleştiremiyordu; her harcama varsayılan olarak eşit şekilde bölünüyordu. v1.5 ile kullanıcılar artık hem proje hem de kategori bazında özel oranlar belirleyebiliyor. Bu değişiklik, çiftlerin ve arkadaşların paylaşılan masraflarını daha gerçekçi bir şekilde bölmesine olanak tanıyor, sadece basit bir 50:50 değil. Ekim ayından itibaren günlük masraflar için 60:40 oranında yeni bir muhasebe projesi başlatabilirken, apartman kiranızı sizin için adil hissediyorsa 50:50 eşit tutabilirsiniz. Ve eğer market alışverişleri 70:30, faturalar ise 62:38 daha dengeli geliyorsa, bu oranları aynı proje içinde kategori bazında ayrı ayrı atayabilirsiniz.

v1.5'teki en belirgin değişiklik, proje üyelerini ekleyip her bir kişiye varsayılan bir pay atayabileceğiniz yeni Üye & Varsayılan Paylar bölümüdür. Bir projede iki üye varsa, oran 50:50, 40:60 veya ne doğru geliyorsa o olabilir. Üç üyeyle, oran 33.33:33.33:33.34, 50:25:25 veya istediğiniz herhangi bir kombinasyon olabilir. Bu, projenin varsayılan bölmesi olur. Bunun altında, eğer projenin varsayılanından farklı olmasını isterseniz, her kategorinin payını ayarlamak için aşağı kaydırabilirsiniz. Bir kategoriye özel bir oran atadığınızda, mavi oran işareti turuncuya döner — kategorinin proje genelinden farklı bir kural kullandığına dair küçük bir görsel ipucu. Bu değişiklik proje ayarlarına çok daha fazla esneklik kazandırırken, proje oluşturma/düzenleme görünümünü biraz daha karmaşık hale getiriyor. Buna yardımcı olmak için, her bölüme küçük SSS yardımcılarını görebileceğiniz bilgi düğmeleri ekledim.

Bu değişikliği uygulamak beklediğimden daha karmaşıktı. Splync her zaman temiz bir 50:50 dünyası varsaymıştı — tek bir sayı, her yerde uygulandı ve matematik yapıldı. Özel oranları destekleme kararı aldığımda, tüm iç yapının yeniden düşünülmesi gerekiyordu. Artık bir proje tek bir paylaşılan yüzdeye güvenemezdi. Her kategorinin kendi oranına ihtiyacı vardı ve her harcamanın hem proje düzeyinde varsayılan hem de kategori düzeyinde geçersiz kılma referansı olması gerekiyordu. Bunu gerçekleştirmek için, hesaplama mantığını temelden yeniden yazdım. Her harcama artık küçük bir karar ağacı taşır: "Bu kategorinin kendi oranı var mı? Evetse, onu kullan. Değilse, proje oranına geri dön." Açıklarken basit geliyor ama uygulama genelinde veri modelini tutarlı tutmak — iOS görünümleri, FastAPI arka planı ve MariaDB şemaları — beklediğimden daha dikkatli bir ayarlama gerektirdi.

Sunucu tarafına dokunan herhangi bir güncelleme son derece dikkatli bir şekilde ele alınmalıdır. Eğer yanlışlıkla mevcut sunucu kodunu değiştirirseniz, hala v1.4'te olan kullanıcılar anında hatalar veya sistem hatalarıyla karşılaşır. Örneğin, v1.5 için sunucu programı, proje ayarlarının oran verilerini içermesini bekler, ancak v1.4 uygulaması hiçbir oran içermeyen proje ayarları gönderir. Bu iki sürüm iletişim kurmaya çalıştığında istek başarısız olur — çünkü biraz farklı "diller" konuşurlar. Geliştiriciler, tabii ki, test ortamında güvenli değişiklikler yapabilirler. Zor kısım, mevcut kullanıcılar hala v1.4'teyken Apple’ın incelemesi için yeni bir sürüm gönderdikten sonra başlar. Gönderimden sürüm yayınlanmasına kadar olan süre boyunca, sunucunun her iki sürümü de aynı anda desteklemesi gerekir, böylece Apple inceleyicileri v1.5'i test edebilir ve mevcut kullanıcılar v1.4'ü kesintisiz kullanmaya devam edebilir.

Uygulama geliştirmede, bir “endpoint” sadece uygulamanın sunucuya isteklerini gönderdiği yerdir — şehirdeki belirli bir sayaç gibi. Bir sayaç evlilik kayıtlarını, bir diğeri ikamet kayıtlarını, bir diğeri de pasaportları ele alır. Uygulamalar da aynı şekilde çalışır: Her endpoint sunucunun belirli bir tür isteği kabul ettiği özel bir penceredir, örneğin giriş, proje oluşturma, harcama düzenleme, arkadaş isteği vb. Splync v1.4 bir istek gönderdiğinde, eski formatı anlayan “eski” pencereye gider. Splync v1.5 ise oran verilerini anlayan “yeni” pencereye istek gönderir. Eğer sunucu eski pencereyi çok erken kapatsaydı, v1.4 kullanıcılarının verilerini “sunacakları” bir yer kalmazdı. Bu nedenle, bir güncelleme sırasında, sunucu her iki pencereyi de açık tutmalı — her iki endpointi — her kullanıcı güvenli bir şekilde yeni sürüme geçene kadar. Dürüst olmak gerekirse, aynı anda bu iki pencereyi yönetmek fazladan bir boyutta düşünmek gibiydi.

Splync v1.5 projeye ve kategoriye göre bölme oranlarını özelleştirebiliyor, ancak henüz tek harcama bazında değil. Tek harcama bazında oranları desteklemek için başka bir yapısal katmana ihtiyacımız var — esasen her harcamanın paylarını nasıl depolayıp hesapladığını daha derin bir şekilde yeniden yazmak. Ayrıca, sadece daha fazla güç eklemek adına uygulamanın arayüzünü aniden karmaşık hale getirmemeye dikkat etmeliyiz. Bu, göründüğünden daha büyük bir yükseltme. Oraya ulaşmak için bize biraz daha zaman verin. Ufukta ve oraya ulaşacağız. O zamana kadar, yeni proje ve kategori bazında oranların paylaşılan harcamaları nasıl daha esnek hale getirdiğini keşfedelim.