Uygulama Ne Zaman Yeniden Yazılmalı?
Yazılım projelerinde en cazip ve en riskli cümle şudur: “Bunu baştan yazalım.” Kulağa temiz bir çözüm gibi gelir; gerçekte çoğu zaman mevcut sorunları çözmez, yenilerini ekler. Yeniden yazım bazen doğru karardır ama bu, kanıtlanması gereken bir iddiadır. 🔄
Bu yazı yeniden yazım kararını beş sinyalle test ediyor. Bakım kurgusunu bakım yazısında anlattık.
Yeniden Yazım Neden Riskli?
Sıfırdan başlamak, sıfıra dönmek demektir. ⚠️
Birikmiş Bilgi Kaybolur
Mevcut koddaki her ayrıntı bir sorunun çözümüdür. Baştan yazarken bu çözümler yeniden keşfedilir.
Uzun Sessizlik
Yeniden yazım sırasında yeni özellik gelmez. Kullanıcı bu dönemi fark eder.
Maliyet Genellikle Aşılır
“Nasılsa biliyoruz” varsayımı, ilk projeden daha uzun süren bir işe dönüşebilir.
Sinyal 1: Teknoloji Desteği Bitti
En sağlam ve tartışmasız sinyal. 🧱
Ne Oluyor?
Kullanılan teknoloji ya da kütüphane artık desteklenmiyor. Güvenlik güncellemesi gelmiyor.
Neden Ertelenmez?
Yeni işletim sistemi sürümlerine uyum imkânsız hale gelir.
Karar
Bu durumda yeniden yazım bir tercih değil zorunluluktur.
Sinyal 2: Her Değişiklik Pahalı
Ölçülebilir bir sinyal: değişim maliyeti. 💸
| Belirti | Anlamı |
|---|---|
| Küçük değişiklik uzun sürüyor | Kod karmaşık |
| Her düzeltme yeni hata çıkarıyor | Yapı kırılgan |
| Geliştirici kodu anlamıyor | Dokümantasyon yok |
| Test edilemiyor | Risk yüksek |
Nasıl Ölçülür?
Son bir yılda basit bir değişiklik ortalama ne kadar sürdü? Bu süre artıyorsa sorun yapısaldır.
Önce İyileştirme
Kodun sorunlu bölümleri parça parça düzeltilebilir. Bu yol her zaman önce denenmelidir.
Sınır Nerede?
İyileştirme maliyeti yeniden yazıma yaklaşıyorsa karar değişir.
Sinyal 3: Platform Değişimi
Teknoloji tercihi artık uymuyorsa. 📱
Tek Platformdan İkiye
Native tek platformla başlandıysa ikinci platform için yeni bir kod gerekir.
Yaklaşım Değişimi
Çapraz platforma geçiş performans sorunu gerçekten yaşanıyorsa değerlendirilir; ayrımını türler yazısında yaptık.
Ölçümle Karar
Performans şikâyeti varsayım değil, veri olmalıdır.
Sinyal 4: İş Modeli Değişti
Uygulama artık başka bir işi yapıyorsa. 🔀
Yeni Kullanıcı Tipi
Uygulama tek tip kullanıcı için tasarlandıysa ve şimdi çok rollü bir yapı gerekiyorsa temel yetmeyebilir.
Ölçek Değişimi
Kullanıcı sayısı kat kat arttıysa altyapı yeniden kurgulanabilir.
Kısmi Çözüm
Genellikle tüm uygulama değil, yalnızca backend yeniden yazılır. Bu, çok daha ucuzdur.
Sinyal 5: Kaynak Kod Yok
En sık ve tamamen önlenebilir sebep. 🗝️
Ne Oluyor?
Geliştiriciye ulaşılamıyor, kod teslim alınmamış. Uygulama güncellenemiyor ve başka seçenek kalmıyor.
Bedeli
Yeniden yazım maliyeti, ilk projeye yakın ya da üstünde olur.
Nasıl Önlenir?
Kod teslimi ve hesap sahipliği sözleşmeye yazılır; denetimini teklif yazısında yaptık.
Önce Denenecek Üç Yol
Yeniden yazıma geçmeden üç seçenek var. 🔧
Birikmiş Bakımı Yapın
Uyum güncellemeleri toplu yapıldığında uygulama ayağa kalkabilir. En ucuz yol budur.
Parça Parça Yenileyin
Sorunlu ekranlar ve modüller tek tek yeniden yazılabilir. Uygulama yayında kalır.
Sadece Backend’i Yenileyin
Sorun veri tarafındaysa arayüz korunabilir. Bu, tam yenilemenin çok altında maliyettedir.
Kısmi Yenileme Nasıl Yapılır?
Uygulamayı yayında tutarak yenilemek mümkündür. 🔩
Üç yaklaşım, riski dağıtır.
Ekran Ekran
En sorunlu ekranlardan başlanır. Kullanıcı değişimi kademeli görür.
Modül Modül
Ödeme ya da bildirim gibi bir modül tek başına yenilenir.
Katman Katman
Önce backend, sonra arayüz. Veri tarafı sağlamsa arayüz daha ucuza yenilenir; hesabını bütçe yazısında kurduk.
Yeniden Yazım Kararı Verilirse
Doğru kurgu, riski küçültür. 📋
Kapsamı Küçültün
Yeni sürüm eskisinin birebir kopyası olmamalı. Kullanılmayan özellikler taşınmamalıdır.
Kullanım Verisine Bakın
Hangi ekranlar gerçekten kullanılıyor? Bu liste yeni kapsamı belirler.
Aşamalı Geçiş
Eski uygulama yayında kalırken yenisi hazırlanır. Kesinti en aza iner.
Veri Taşıma Planı
Kullanıcı hesapları ve geçmiş veriler nasıl aktarılacak? Bu ayrı bir iştir; hesabını bütçe yazısında kurduk.
Karar Testi
Dört soru, kararı büyük ölçüde verir. 🧭
1. Teknoloji Destekleniyor mu?
Desteklenmiyorsa yeniden yazım zorunludur.
2. Kod Elinizde mi?
Değilse başka seçenek yoktur.
3. Bakım Yapıldı mı?
Yapılmadıysa önce onu deneyin; sorun orada olabilir.
4. İyileştirme Maliyeti Ne?
Yeniden yazıma yaklaşıyorsa karar netleşir; senaryoları başarısızlık yazısında topladık.
Sık Sorulan Sorular
Uygulamam eskidi, yeniden mi yazdırmalıyım?
Önce sebebi ayırt edin. Yeniden yazım taleplerinin önemli bir kısmında kod sorunlu değildir; uygulama sadece bakım almamıştır. İki üç yıllık birikmiş uyum güncellemeleri toplu yapıldığında uygulama çalışır hale gelebilir ve bu, yeniden yazımın çok altında bir maliyettir. Yeniden yazım ancak teknoloji desteği bittiyse veya kod elinizde değilse zorunludur.
Yeniden yazım neden riskli?
Çünkü sıfırdan başlamak birikmiş bilgiyi de sıfırlar. Mevcut koddaki her ayrıntı geçmişte çözülmüş bir sorunun izidir ve baştan yazarken bunlar yeniden keşfedilir. Ayrıca süreç boyunca yeni özellik gelmez, kullanıcı bu sessizliği fark eder ve maliyet genellikle tahminlerin üstüne çıkar. Kademeli iyileştirme çoğu durumda daha güvenlidir.
Yeniden yazım kararı verirsem nasıl ilerlemeliyim?
Dört ilkeyle. Kapsamı küçültün; yeni sürüm eskisinin birebir kopyası olmamalı ve kullanılmayan özellikler taşınmamalı. Kullanım verisine bakarak hangi ekranların gerçekten kullanıldığını belirleyin. Eski uygulama yayında kalırken yenisini hazırlayın. Kullanıcı hesapları ve geçmiş veriler için ayrı bir taşıma planı yapın.