Çoğu geliştirici finans uygulamalarına tamamen matematiksel bir problem olarak yaklaşır: Faizi ne pahasına olursa olsun en aza indir.
Teknik açıdan bu, Çığ Yöntemi’dir. Borçları faiz oranına göre azalan sırayla sıralar ve fazla nakdi en üsttekine yönlendirirsiniz. Matematiksel olarak en verimli yol budur.
Ancak TinyDebt’i geliştirirken, “matematiksel olarak doğru” kodun çoğu zaman “insan testinde” başarısız olduğunu fark ettim. Bu da beni Kartopu Yöntemi’ni, yani bakiye büyüklüğüne göre sıralamayı uygulamaya götürdü; teknik uygulama bana kullanıcı odaklı mantık hakkında çok şey öğretti.
Mantık: Başarı için Sıralama
Yerel öncelikli bir React Native ortamında bu hesaplamaları backend olmadan yapmak, istemci tarafı mantığının hızlı ve güvenilir olması gerektiği anlamına gelir. Kullanıcıların “Matematiksel Verimlilik” ile “Psikolojik İvme” arasında geçiş yapmasına izin vermek için kullandığım mantığın basitleştirilmiş bir sürümü burada:
type Debt = {
id: string;
name: string;
balance: number;
interestRate: number;
};
// The "Avalanche" Logic: Maximizing Interest Savings
const getAvalancheOrder = (debts: Debt[]) => {
return [...debts].sort((a, b) => b.interestRate - a.interestRate);
};
// The "Snowball" Logic: Maximizing Psychological Wins
const getSnowballOrder = (debts: Debt[]) => {
return [...debts].sort((a, b) => a.balance - b.balance);
};Teknik Zorluk: Gerçek Zamanlı Karşılaştırma
Kullanıcı için asıl değer yalnızca bir liste görmek değil, seçiminin etkisini görmek. TinyDebt’te, kullanıcının aylık “ekstra” ödemesi üzerinden her iki algoritmayı da çalıştırıp iki farklı “Borçsuz Kalma Tarihi” gösteren bir projeksiyon motoru geliştirmem gerekti.
Uygulama yerel öncelikli olduğu ve basit, gizlilik odaklı bir veri modeli kullandığı için bu hesaplamalar anında gerçekleşir. Bir sunucu amortisman planını hesaplarken beklenen bir yükleniyor göstergesi yok. Sonuç, hızlı yanıt veren ve cesaret verici hissettiren bir arayüz.
“Kartopu” UX Savaşını Neden Kazanıyor?
Çığ yöntemi uzun vadede daha fazla para tasarrufu sağlasa da Kartopu yöntemi daha yüksek bir “tamamlama oranına” sahip.
Programlamada buna sürtünmeyi azaltmak diyoruz:
- Çığ önce devasa, karmaşık bir eski modülü yeniden düzenlemek gibidir. Yapılması gereken doğru şeydir ama yorucudur.
- Kartopu pazartesi sabahı “kolay” üç hatayı düzeltmek gibidir. Salı günü büyük işlerin üstesinden gelmek için gereken dopamini verir.
Sonuç: Yalnızca Veritabanları İçin Değil, İnsanlar İçin Tasarlayın
Araçlar geliştirirken, özellikle de finans alanında, “insan değişkenini” hesaba katmamız gerekir. Her iki seçeneği de minimalist ve gizli bir ortamda sunarak kullanıcıların çok daha uzun süre bağlı kaldığını gördüm.
Bir yardımcı uygulama geliştiriyorsanız kendinize sorun: Mantığım işlemci için mi optimize edildi, yoksa onu kullanan kişi için mi?