Neyi değiştireceğini netleştir: modül mü, platform mu?
İlk adım, yeni isteğin “tek bir ekran ve servis” mi yoksa “mevcut tasarımın sınırlarını zorlayan” bir değişiklik mi olduğuna karar vermektir. Modül ekleme tarafında; yeni UI bileşeni, ek bir iş kuralı, mevcut API’lere ek endpoint gibi parçalara ayrılabilen işler daha uygundur. Yeniden yapım tarafında ise; veri modeli değişecekse, mevcut yetkilendirme yaklaşımı yetersiz kalıyorsa veya performans sorunları yeni modülle büyüyecekse risk artar. Bu ayrım için mevcut modüllerin bağımlılık grafiğini çıkarın: hangi tablolar, hangi paketler ve hangi arayüzler etkileniyor? Etki alanı genişliyse “yenileme” aday olur. Etki alanını somutlaştırmadan karar genelde yanlış olur.
Kod kalitesi teknik borcu ele vermezse karar havada kalır
Modül eklemek kolay gibi görünür ama teknik borç gör��nmezse sürpriz çıkar. Kod kalitesi için hızlı bir tarama yapın: birim test oranı, kod tekrarları, karmaşıklık (cyclomatic complexity), eski kütüphaneler ve standart dışı veri erişimi var mı? Statik analiz raporları ve lint kuralları bir “risk endeksi” çıkarır. Ayrıca mevcut mimaride transaction sınırları doğru tanımlı mı, loglama/izleme var mı, hatalar nasıl ele alınıyor? Bu kontroller özellikle veri aktarımı planında belirleyicidir. Örneğin veri dönüşümü gerekecek bir yenilemede, hatalı exception akışı yüzünden eski verinin taşınması sırasında sessiz bozulma yaşanabilir. Kalite göstergeleri zayıfsa “rebuild” seçeneği daha mantıklı olabilir.
Veri aktarımı sorusu: yeni şema ile eski veri aynı dili mi konuşuyor?
Doğru kararın omurgası veri aktarımıdır. Önce mevcut veri modelini ve yeni modülün gerektirdiği şemayı yan yana koyun. Alanlar aynı isimde olsa bile anlam aynı mı? Örneğin bir “durum” alanı eski sistemde serbest metin iken yeni sistemde enum’a dönüşüyorsa dönüştürme kuralları netleşmeden geçiş yapılamaz. Aktarım planında veri temizleme, eşleştirme ve geriye dönük uyumluluk adımlarını yazın. En kritik kontrol: idempotency. Aktarım işlemi tekrar çalıştırıldığında aynı sonucu üretmeli. Bunun için transform adımlarını “salt okuma + deterministik dönüşüm + benzersiz hedef yazım” prensibiyle tasarlayın. Ayrıca referans bütünlüğünü doğrulayan kontroller (foreign key uyumu, yetim kayıtlar) aktarım öncesi ve sonrası çalıştırılmalıdır.
Operasyon riski: canlıda değişiklik ne kadar süre kesinti ister?
Modül ekleme ile yenileme arasındaki fark, operasyon penceresinde ortaya çıkar. Modül eklemede genelde kısa bir deploy ve sınırlı geri dönüş (rollback) yeterli olabilir. Yenilemede ise geçiş stratejisi belirleyicidir: paralel çalıştırma, “strangler” yaklaşımı, kademeli yönlendirme veya tek seferlik kesme gibi seçenekler vardır. Süreçte en az şu dokümantasyon şart: değişiklik planı, geri dönüş planı, veri doğrulama kriterleri ve izleme göstergeleri. Örneğin aktarım sonrası “iş kuralı tutarlılığı” testleri yapılmazsa kullanıcı fark etmeden hatalı hesaplar oluşabilir. Canlıya geçiş öncesi staging ortamında birebir veri örnekleriyle (maskelenmiş) deneme yapılmalıdır. Tek denemelik, plansız geçiş sık yapılan temel hatadır.
Karar ölçütleri: extend mi rebuild mü? kontrol tablosu
Pratik bir karar çerçevesi kullanın. Aşağıdaki başlıklardan her birinde puanlama yapın: (1) Yeni modülün bağımlılık sayısı (kaç servis/tabloda dokunuyor?), (2) Mevcut kodun anlaşılabilirliği (dokümantasyon, test, standardizasyon), (3) Veri dönüşüm gereksinimi (şema değişimi, anlam dönüşümü, temizlik ihtiyacı), (4) Performans ve ölçeklenme riski (mevcut darboğaz yeni yükle artıyor mu?), (5) Gözlemlenebilirlik (log/trace/metric var mı?), (6) Geri dönüş maliyeti (rollback var mı?). Toplam etki küçük ve veri dönüşümü minimal ise “extend” tercih edin. Etki alanı geniş, testler yetersiz ve veri dönüşümü kuralsızsa “rebuild” daha düşük uzun vadeli risk sağlar. Bu ölçütler olmadan “hızlı yapalım” refleksi teknik borcu kalıcılaştırır.
Doğru mimari planı: modülü eklemenin teknik sınırları
Modül eklemeyi seçerseniz mimariyi boğmadan ilerleyin. Önce mevcut servis sözleşmelerini netleştirin: endpoint davranışı, hata kodları, idempotentlik, versiyonlama. Yeni modülü kapsayıcı bir katmanda (facade/adapter) konumlandırın; böylece eski sistemdeki farklılıklar merkezileşmez. Veri katmanında doğrudan tabloları karıştırmak yerine mevcut DAO/repository desenine uyun; bu, ileride yeniden yapım gerektiğinde geçiş maliyetini düşürür. Ayrıca feature flag ile kademeli açma planlayın. Ekran tarafında veriyi çağırma sıklığı ve cache stratejisi belirlenmeli. Başka ekipler aynı kaynağa yazıyorsa çakışma çözümü (optimistic lock, versiyon alanı) tasarlanır. Bu adımlar yapılmazsa modül çalışır ama sistem davranışı tahmin edilemez hale gelir.
Yeniden yapım planı: aktarım, doğrulama ve paralel geçiş adımları
Rebuild seçeneğinde “kod yazmak” kadar “veriyi doğru taşımak” belirleyicidir. Önce dönüşüm şeması çıkarın: kaynak alan -> hedef alan eşlemesi, null kuralları, dönüştürme fonksiyonları ve hatalı kayıt stratejisi. Ardından aktarım için üç katman hedefleyin: kaynak okuma, dönüşüm, hedef yazım. Her adımı ölçün; satır sayısı, checksum ve örnek kayıt doğrulaması yapın. Paralel geçiş düşünülüyorsa, okuma trafiğini kademeli olarak yeni modele yönlendirin; yazma tarafında “dual write” yerine tutarlı tek kaynak yaklaşımı çoğu durumda daha güvenlidir. En az şu test setini çalıştırın: aktarım öncesi/sonrası veri bütünlüğü, iş kuralı senaryoları, performans testi ve rollback dry-run. En sık hata: aktarımı “tek seferlik batch” gibi görmek ve hatalı satırları izlememek.
Neptün Medya yaklaşımı: risk azaltan teslim planı ve kontrol noktaları
Karar sürecini tek bir görüşmeye değil, somut kontrol noktalarına bağlarız. Önce mevcut sistemde etki haritası çıkarır, bağımlılıkları ve veri değişimini netleştiririz. Sonra kısa bir teknik keşif ile kod kalite sinyallerini (test, standardizasyon, izleme) toplar, veri aktarımı için dönüşüm kurallarını yazarız. Extend seçilirse modülün versiyonlanması, feature flag ve rollback planı proje başlangıcında tasarlanır; rebuild seçilirse aktarım şeması, doğrulama kriterleri ve paralel çalışma stratejisi belirlenir. Tüm ilerleme boyunca “canlıda ne zaman ne değişiyor?” sorusu cevaplanır. Bu yöntem, teknik borcu büyütmeden ilerlemeyi ve operasyon riskini yönetilebilir seviyede tutmayı amaçlar. Neptün Medya için öncelik, kararın yazılımla birlikte işletilebilir hale gelmesidir.
Uygulama sonrası kontrol listesi
- Mobil görünüm, form ve WhatsApp yönlendirmeleri test edilir.
- Title, description, canonical ve sitemap kayıtları kontrol edilir.
- Kırık link, hatalı görsel ve boş CTA alanı bırakılmaz.
- İçerikler gerçek hizmet kapsamıyla uyumlu kalır.