Bir MVP ne zaman yeniden yazılmalı, ne zaman kurtarılmalı?

Bir ürün birkaç ay hızlı geliştirildikten sonra doğal bir cümle ortaya çıkar: 'Bunu baştan yazsak daha kolay.' Bazen doğrudur. Çoğu zaman değildir. Rewrite yeni bir başlangıç hissi verdiği için çekicidir; ama mevcut ürünün öğrendiği bütün edge case'leri yeniden keşfetme maliyeti de getirir.

Kodun kötü görünmesi rewrite sebebi değildir. Sistemin değiştirilemez hale gelmesi olabilir.

Önce borcun türünü ayırıyorum

Kurtarılabilir sistemin işaretleri

• Core data modeli büyük ölçüde doğru.
• Sorunlar belirli domain'lerde yoğunlaşıyor.
• Route ve component'ler aşamalı değiştirilebiliyor.
• Production davranışı ölçülebiliyor.
• Migration sırasında eski ve yeni sistem bir süre birlikte yaşayabilir.

Bu durumda strangler yaklaşımı daha mantıklı olabilir: en problemli domain'i yeni modele taşı, eski katmanı parça parça emekli et.

1old system -> adapter -> new domain -> migrate consumers -> remove old

Rewrite adayının işaretleri

• Core veri modeli ürünün bugünkü gerçekliğini ifade edemiyor.
• Her feature aynı global state ve side effect ağına bağımlı.
• Güvenlik sınırı mimariye sonradan eklenemiyor.
• Platform seçimi ürünün temel ihtiyacını engelliyor.
• En küçük değişiklik bile öngörülemez regresyon üretiyor.
• Sistemin davranışını açıklayacak güvenilir test veya telemetry kurmak aşırı maliyetli.

Rewrite maliyetini eksik hesaplamayın

Yeni repository açmak maliyetin küçük kısmı. Gerçek maliyet auth, migration, eski kullanıcı verisi, ödeme durumu, deep link, SEO URL'leri, mağaza paketleri, analytics, edge case ve operasyon bilgisini yeniden taşımak.

1const rewriteCost =2  implementation +3  dataMigration +4  regressionDiscovery +5  parallelOperation +6  userMigration +7  releaseRisk;

Ürün hâlâ doğrulanmadıysa rewrite daha tehlikeli

Henüz product-market fit sinyali zayıfken mimariyi mükemmelleştirmek, bilinmeyen ürünü ikinci kez inşa etmek olabilir. Önce ürün riskini azaltmak gerekir.

Doğrulanmamış bir ürünü yeniden yazmak, belirsizliği daha temiz kodla yeniden üretmek olabilir.

Karar matrisi

1function decide({ coreModelWrong, securityBlocked, changeCost, productValidated }: Signals) {2  if (!productValidated) return 'stabilize-and-learn';3  if (coreModelWrong && securityBlocked && changeCost === 'extreme') return 'rewrite-candidate';4  return 'incremental-rescue';5}

Benim varsayılanım: kurtar

Rewrite'ı ispatlanması gereken seçenek olarak görüyorum. Önce audit, kaynak doğrusu, domain izolasyonu, performans ölçümü ve gereksiz feature temizliği. Bunlar yapıldıktan sonra sistem hâlâ her değişiklikte direniyorsa rewrite artık duygusal değil, kanıta dayalı karar olur.