Yazılım projesi neden arayüzde değil veri modelinde batar?

Yazılım projelerinin çoğu arayüzde değil veri modelinde batıyor: ürünün kaç fiyatı olabileceği, bir müşterinin kaç alt kullanıcısı olacağı ya da bir kaydın silindiğinde ne olacağı baştan yanlış kurulursa, sonradan düzeltmek ekranı değiştirmekten kat kat pahalıya geliyor. Bu yüzden geliştirmeye başlamadan önce tabloları, ilişkileri ve indeksleri yazıyoruz; ekran bundan sonra geliyor.

Veri modeli nedir, ekranla ilişkisi ne

Veri modeli, yazılımın hangi bilgileri hangi yapıda tutacağını tanımlayan plandır: hangi tablolar var, aralarındaki ilişki nasıl, bir kayıt hangi alanları zorunlu kılıyor, hangi değer hangi birimde tutuluyor. Ekranlar bu planın bir görünümü; planın kendisi değil.

Aradaki fark pratikte şöyle beliriyor. Bir ekranı değiştirmek bir günlük iş olabiliyor, çünkü yalnızca o ekranı etkiliyor. Bir tablo yapısını değiştirmek ise ona bağlı her ekranı, her raporu, her entegrasyonu ve mevcut bütün kayıtları etkiliyor. İkisinin maliyeti aynı ölçekte değil ve proje ilerledikçe fark büyüyor.

Bu yüzden analiz çıktısı doğrudan koda değil önce veri modeline dönüşüyor. İşi yapan kişiyle oturup çıkardığımız akış — kayıt nereden giriyor, kimin onayından geçiyor, hangi noktada duruyor — tablo ve ilişki listesine çevriliyor ve geliştirmeye başlamadan önce yazılı olarak onaylanıyor.

Baştan verilmesi gereken kararlar

Deneyimimizde bir projenin ömrünü belirleyen kararlar şu beş başlıkta toplanıyor:

• Çokluk soruları. Bir ürünün kaç fiyatı olabilir? Bir müşterinin kaç adresi, kaç alt kullanıcısı? Bir siparişin kaç sevkiyatı? Bu soruların cevabı bire bir sanılıp tek alan olarak kurulduğunda, ikinci kayıt geldiği gün yapı kırılıyor.
• Kimlik ve eşleşme. Bir ürünü ne tanımlıyor: stok kodu, barkod, yoksa dışarıdan gelen bir numara? Kayıtların dış sistemlerle eşleşeceği alan baştan belirlenmezse, entegrasyon aşamasında geriye dönük eşleme işi çıkıyor.
• Silme davranışı. Kayıt gerçekten siliniyor mu, yoksa pasife mi alınıyor? Buna bağlı geçmiş kayıtlar ne oluyor? Gerçek silme, geçmiş siparişlerin içindeki ürün adını da götürüyor.
• Para, birim ve kur. Fiyat hangi para biriminde, vergi dahil mi hariç mi, hangi günün kuru kullanılıyor? Fiyatı tek bir ondalık alana yazmak bu soruların hepsini belirsiz bırakıyor.
• Yayın ve görünürlük. Aynı kaydın farklı yerlerde farklı durumda olması gerekiyor mu? Bir ürün bir kanalda yayında, diğerinde kapalı olabiliyorsa bu bir alan değil ayrı bir ilişki tablosu demek.

Para ve birim: en sık yanlış kurulan alan

Fiyat alanı, veri modelinin en çok hafife alınan kısmı. Kendi grubumuzda işlettiğimiz sistemde fiyatlar panelde vergi hariç ve büyük kısmı dolar cinsinden duruyor; son kullanıcıya dönük sitelerde ise günlük kurla Türk lirasına çevrilip vergi dahil gösteriliyor. Bu üç dönüşümün (para birimi, vergi, kur tarihi) her biri veri modelinde ayrı bir karar.

Bu kararlar yazılı değilse ortaya çıkan tablo şu oluyor: aynı ürün iki ekranda iki farklı fiyatla görünüyor, kimse hangisinin doğru olduğunu söyleyemiyor ve sorun bir ekran hatası gibi aranıyor. Oysa sorun ekranda değil, fiyatın hangi biçimde saklandığının tanımlanmamış olmasında.

Doğru kurulum, saklanan değer ile gösterilen değeri ayırmak: veritabanında kaynak para birimi, vergi oranı ve geçerlilik tarihi ile birlikte tek bir doğru değer durur; gösterim tarafında hesaplama yapılır. Böylece bir vergi oranı değiştiğinde geçmiş kayıtlar bozulmuyor.

Silme, arşiv ve geçmişin korunması

Gerçek kayıtları geri dönüşü olmayan biçimde silmemek bizim kendi sistemlerimizde de uyguladığımız bir kural. Veri modelinde bunun karşılığı, kayıtların pasife alınabilmesi ve geçmiş işlemlerin kendi anındaki bilgiyi taşımasıdır.

İkinci satır özellikle önemli: sipariş satırında yalnızca ürün numarası tutulursa, ürünün adı ya da fiyatı bir yıl sonra değiştiğinde geçmiş siparişler de değişmiş görünüyor. Muhasebe ile karşılaştırma yapıldığında tutmayan sayıların kaynağı genellikle tam burası oluyor.

Performans da bir model konusu

Yavaşlık çoğu zaman sunucu gücüyle değil modelle ilgili. Hangi alanlarda arama yapılacağı ve hangi sorguların sık çalışacağı baştan biliniyorsa indeksler ona göre konuyor. Listeleme ekranlarının sayfalanması, raporların önceden hesaplanmış toplamlardan okunması ve çok kayıtlı tabloların tarih aralığıyla bölünmesi gibi kararlar da model aşamasında alınıyor.

Tersi durumda şu tabloyla karşılaşılıyor: sistem on bin kayıtla hızlı, beş yüz bin kayıtla kullanılamaz hale geliyor. Bu noktada eklenen sunucu kapasitesi zaman kazandırıyor, sorunu çözmüyor.

Kısa kontrol listesi

• Çokluk soruları (bir kaydın kaç tanesi olabilir) yazılı olarak cevaplandı mı?
• Dış sistemlerle eşleşme hangi alan üzerinden yapılacak, belirlendi mi?
• Silme davranışı pasife alma olarak mı kuruldu?
• Fiyat; para birimi, vergi ve geçerlilik tarihiyle birlikte mi saklanıyor?
• Geçmiş işlemler o anki bilgiyi taşıyor mu?
• Sık çalışacak sorgular ve indeksler model aşamasında düşünüldü mü?
• Veri modeli geliştirmeye başlamadan önce yazılı olarak onaylandı mı?

KAV Yazılım projelerde bu sırayı izliyor: analiz, veri modeli, sonra ekran. Aynı yöntemi grup içindeki ürün, fiyat, stok ve cari verisini tek yerde tutan yönetim panelini kurarken de uyguladık.