Mevcut Yazılıma Yeni Özellik Eklemek Neden Bazen Sıfırdan Yazmaktan Daha Pahalıya Mal Olur?

Bir kurucu geçenlerde bana geldi: mevcut CRM'e 'basit' bir özellik eklemek istiyordu — müşteri kartına bir 'sadakat puanı' alanı ve buna göre otomatik indirim kuralı. Teklif istedi, üç farklı yazılım ekibinden fiyat aldı. Üçü de, sıfırdan benzer büyüklükte küçük bir modül yazmaktan daha yüksek bir rakam verdi. Kurucunun tepkisi tanıdıktı: 'Bu kadar küçük bir şey nasıl bu kadar pahalı olur?' Bu, yazılım geliştirmede en çok yanlış anlaşılan konulardan biri: yeni özellik eklemek neden bazen sıfırdan yazmaktan daha pahalıya mal olur, ve bunun nedeni tembellik ya da fahiş fiyatlandırma değil, oldukça mantıklı bir mühendislik gerçeği.

##Yeni özellik eklemek neden bu kadar sezgiye aykırı geliyor?

Sıfırdan yazarken hiçbir şeyi bozma riskin yok. Boş bir sayfadasın, istediğin veri modelini kurarsın, istediğin kütüphaneyi seçersin, test etmen gereken tek şey yeni yazdığın kod. Mevcut bir sisteme özellik eklerken durum tam tersi: her satır, üzerine yazılı olmayan ama koda gömülü yüzlerce varsayımla etkileşime giriyor. 'Sadakat puanı' alanı eklemek basit bir migration gibi görünür ama o alanı okuyan raporlama ekranı, o alanı güncelleyen üç farklı entegrasyon (POS, e-ticaret, muhasebe) ve o alanın null olma ihtimalini hiç düşünmemiş eski bir fatura hesaplama fonksiyonu varsa, 'basit alan ekleme' işi bir haftalık regresyon testine dönüşür. Sıfırdan yazan geliştirici bu varsayımlarla hiç uğraşmaz; mevcut sisteme dokunan geliştirici önce o varsayımları bulmak, sonra onlarla güvenle çalışmak zorunda.

##Asıl maliyeti belirleyen şey: bağımlılıklar ve görünmeyen iş

Bir özelliğin gerçek maliyeti, yazılacak kod satırı sayısıyla değil, o kod satırlarının sisteme kaç yerden bağlı olduğuyla ölçülür. Bu bağlılık miktarına genelde 'coupling' denir ve yıllar içinde birikir — her kısayol, her 'şimdilik böyle çözelim' kararı, her test yazılmadan geçen deploy, gelecekte bir özelliğin maliyetine ekstra bir kat daha ekler. Görünmeyen iş genelde şu başlıklarda saklanır:

• ▸Veri geçişi: yeni alanın eski kayıtlarda ne olacağına karar vermek (varsayılan değer mi, backfill mi, manuel düzeltme mi)
• ▸Test kapsamı: mevcut testler yeterince kapsamlı değilse, her değişiklik 'kırdım mı, kırmadım mı' belirsizliğiyle geliyor
• ▸Entegrasyon etkisi: özelliğin dokunduğu her dış sistemin (ödeme, muhasebe, e-ticaret) davranışını yeniden doğrulamak
• ▸Performans: yeni sorgu veya alan, zaten yüklü bir tabloyu daha da yavaşlatabilir
• ▸Ekip hafızası: kodu yazan kişi ayrılmışsa, mevcut mantığı anlamak başlı başına bir araştırma projesi
• ▸Geriye dönük uyumluluk: özelliği kullanmayan mevcut müşterilerin akışını bozmamak

##Gerçek bir senaryo: bir rezervasyon SaaS'ına 'basit' bir özellik eklemek

Diyelim ki bir randevu/rezervasyon SaaS'ı işletiyorsun, 40 kadar küçük işletme müşterin var, ürün üç yıldır ayakta. Bir müşteri 'çoklu personel seçimi' istiyor — randevu alırken hangi çalışanla görüşüleceğini seçebilme. Kulağa küçük geliyor: bir dropdown, bir foreign key. Ama koda bakınca şunu görüyorsun: randevu tablosu üç yıl önce 'her randevu bir işletmeye aittir, personel kavramı yok' varsayımıyla kurulmuş. Müsaitlik hesaplama fonksiyonu işletme bazında çalışıyor, personel bazında değil. Bildirim sistemi 'işletmeye randevu geldi' e-postası atıyor, 'şu personele' değil. Raporlama ekranı ciroyu işletme başına gösteriyor, personel kırılımı yok. Takvim entegrasyonu (Google Calendar senkronu) tek bir işletme takvimine yazıyor.

Bu noktada geliştirme ekibi iki seçenekle karşılaşır. Birincisi: personel kavramını gerçek bir veri modeli olarak sisteme sokmak — randevu, müsaitlik, bildirim, raporlama ve takvim entegrasyonunun beşinde de değişiklik, artı geriye dönük veri geçişi (mevcut 40 müşterinin randevularına 'varsayılan personel' atamak) artı her akışın regresyon testi. Bu kolayca üç-dört haftalık bir iş olur. İkincisi: özelliği yüzeysel şekilde eklemek — sadece dropdown'ı göstermek, arkada gerçek mantığı bağlamamak. Bu bir hafta sürer ama altı ay sonra 'personel bazlı raporlama neden yanlış' diye başka bir talep olarak geri gelir, o zaman maliyet ikiye katlanmış olur. Kurucunun gördüğü teklif farkı işte bu: 'basit özellik' fiyatı, aslında üç-dört haftalık gizli mühendislik işinin karşılığı.

##Maliyeti öngörülebilir kılmanın yolları

Bu maliyeti sıfıra indiremezsin ama görünür ve öngörülebilir hale getirebilirsin. Deneyimli bir ekip, teklif vermeden önce şu adımları atlamaz:

• ▸Özelliğin dokunduğu her tabloyu ve fonksiyonu haritalamak (kod tabanında arama, bağımlılık grafiği)
• ▸Mevcut testlerin o alanı kapsayıp kapsamadığını kontrol etmek — kapsamıyorsa önce test yazmanın maliyetini teklife eklemek
• ▸Veri geçişi senaryosunu somutlaştırmak: eski kayıtlara ne olacak, kim onaylayacak
• ▸Entegrasyon sahiplerine (ödeme, muhasebe sağlayıcısı vb.) değişikliğin onlara etkisini sormak
• ▸Yüzeysel çözüm ile kalıcı çözüm arasındaki farkı ve gelecekteki faturasını müşteriye açıkça yazmak

Bu adımları atlayan teklifler genelde ya çok düşük fiyatlanır (ve proje yarıda sürünceye döner) ya da müşteri şaşkınlıkla 'neden bu kadar pahalı' diye sorar. İkisi de güven kaybettirir. Şeffaf bir maliyet dökümü — 'bu kısmı 3 gün, bu kısmı 5 gün, çünkü şu üç sistemi de güncellememiz gerekiyor' — çoğu zaman fiyatın kendisinden daha ikna edicidir.

Somut bir örnek vermek gerekirse: yukarıdaki randevu SaaS'ı senaryosunda ekip teklifi kalemlere ayırdığında şöyle bir tablo çıkar ortaya — veri modeli değişikliği ve migration için 5 gün, müsaitlik hesaplama mantığının personel bazlı çalışması için 6 gün, bildirim ve raporlama ekranlarının güncellenmesi için 4 gün, takvim entegrasyonunun personel bazlı senkrona geçmesi için 3 gün, tüm akışların regresyon testi için 3 gün. Toplam 21 iş günü, yani dört haftaya yakın bir süre. Müşteri bunu görünce 'basit özellik' beklentisiyle geldiği fiyatın nereden geldiğini anlıyor — ve genelde itiraz etmiyor, çünkü rakam havadan gelmiyor, gerçek bir dökümden geliyor.

##Ne zaman gerçekten sıfırdan yazmak daha ucuza gelir?

Yukarıdaki mantık, 'her zaman ekle, asla yeniden yazma' anlamına gelmiyor. Bazı noktalarda birikmiş bağımlılık o kadar ağırlaşır ki, üzerine inşa etmek yeniden yazmaktan gerçekten daha pahalıya gelir. Bunun sinyalleri genelde şunlardır: her küçük değişiklik birden fazla ekibin onayını gerektiriyor; aynı büyüklükteki özellikler zamanla giderek daha uzun sürüyor (bu, teknik borcun arttığının en net göstergesi); orijinal mimari kararı (örneğin 'her müşteri tek bir işletmeye ait' varsayımı) artık işin gerçek şeklini karşılamıyor; ve kodu anlayan kimse kalmamış, her değişiklik arkeolojiye dönüşüyor. Bu durumda 'küçük özellik' teklifleri gerçekten de sürekli şişmeye başlar — ve bu, yeniden yazmayı düşünme zamanı geldiğinin işaretidir, tek seferde değil, genelde parça parça (bir modülü izole edip yeniden yazarak) yapılan bir süreç.

Bunu somutlaştıran bir başka örnek: üç yıl önce 'tek şube' varsayımıyla yazılmış bir stok sistemi düşün. İlk yıl yeni bir rapor eklemek 2 gün sürüyordu. İkinci yıl şube sayısı artınca aynı büyüklükteki bir rapor 5 güne çıktı, çünkü her sorgunun şube filtresiyle yeniden yazılması gerekiyordu. Üçüncü yılda bu 9 güne çıktı, çünkü raporlama, stok senkronizasyonu ve fatura mantığı birbirine o kadar dolanmıştı ki tek bir değişiklik üç modülü aynı anda etkiliyordu. İşte bu eğri — aynı boyuttaki işin sürekli uzaması — bir ekibin 'artık üzerine eklemek değil, çekirdek modülü yeniden yazmak daha ucuz' kararını vermesi gereken noktayı gösterir.

• ▸Aynı boyuttaki özellikler geçen yıla göre 2 kattan fazla sürüyorsa
• ▸Yeni geliştirici koda 'giriş yapmak' için haftalar harcıyorsa
• ▸Temel veri modeli artık işin gerçek şeklini temsil etmiyorsa (ör. tek şubeden çok şubeye geçiş)
• ▸Test yazmak, kodun kendisinden daha zor hale gelmişse
• ▸Her deploy'da 'bir yerde bir şey kırılır mı' korkusu ekip kültürüne yerleşmişse

##Sık Sorulan Sorular

>Bir özellik teklifinin gerçekçi olup olmadığını nasıl anlarım?

İyi bir teklif, işi parçalara ayırır ve her parçanın neden o kadar sürdüğünü açıklar (kaç sistemin dokunulduğu, veri geçişi var mı, test kapsamı ne durumda). Tek satırlık 'X gün' teklifleri genelde ya yüzeysel çözüm öneriyordur ya da sürpriz fatura riski taşır.

>Küçük bir bütçeyle başlayan bir proje bu tuzağa nasıl düşmez?

En etkili yöntem, en başından itibaren test yazmak ve veri modelini gereksiz yere daraltmamak — örneğin 'şimdilik tek şube var' diye kodu tek-şube varsayımıyla sıkı sıkıya kilitlememek. Bu, başta biraz daha yavaş ilerlemek anlamına gelir ama iki yıl sonra 'basit' bir özelliğin maliyetini büyük ölçüde düşürür.

>Mevcut bir yazılıma özellik eklemek yerine ne zaman ayrı bir modül/mikroservis yazmak mantıklı olur?

Özellik, mevcut sistemin veri modeliyle temelden çelişiyorsa (ör. gerçek zamanlı bir stok senkronizasyonu, toplu iş yapan bir sisteme eklenmeye çalışılıyorsa) ayrı bir servis olarak yazıp mevcut sistemle API üzerinden konuşturmak, hem daha hızlı hem daha güvenli olabilir. Ama bu kendi karmaşıklığını (iki sistemi senkron tutmak) getirir, o yüzden varsayılan değil, istisna olarak düşünülmeli.

>Bu tür bir teklif alırken hangi soruları sormalıyım?

Şunları sorabilirsin: bu özellik hangi tabloları/servisleri etkiliyor, mevcut testler bu alanı kapsıyor mu (kapsamıyorsa test yazmak teklife dahil mi), eski verilerde bu alan için ne yapılacak, bu değişiklik başka bir entegrasyonu (ödeme, muhasebe, e-ticaret) etkiler mi. Yanıtlar net ve somutsa, teklif muhtemelen gerçekçi. Yanıtlar 'sorun olmaz, hallederiz' gibi genel geçiyorsa, sürpriz fatura riski yüksektir.

Bir özellik teklifi aldığında fiyattan çok, o fiyatın nereden geldiğine bakmakta fayda var — hangi sistemlere dokunuyor, veri geçişi var mı, test kapsamı ne durumda. Böyle bir teklifi birlikte gözden geçirmek istersen, iletişim sayfasından yazabilirsin.