Preview Kodunu Temizlemek: Prototip Karmaşasından Modüler Mimariye Geçiş

Hızlı prototipleme araçlarının en büyük avantajı aynı zamanda en büyük riski: ürün çok erken 'bitmiş' gibi görünür. Ekranlar çalışır, butonlar tıklar, auth görünür ve birkaç gerçek kullanıcı bile sistemi kullanabilir. Fakat kod tabanının içinde aynı component'in üç varyasyonu, birbirinden habersiz state kaynakları, API çağrılarının UI içine gömülmesi ve any ile kapatılmış tip boşlukları birikmiş olabilir.

Production refactor'un amacı temiz kod estetiği değil; değişiklik yaparken neyin kırılacağını öngörebilmektir.

1. Önce refactor değil, haritalama

İlk işim dosya taşımak veya component bölmek değil. Sistemin gerçek akışını çıkarıyorum: route'lar, kritik kullanıcı akışları, veri kaynakları, mutation noktaları, global state, local state, cache ve platforma özel davranışlar. Bu harita olmadan yapılan refactor çoğu zaman sadece karmaşayı başka klasöre taşır.

1type RefactorMap = {2  criticalFlows: string[];3  stateOwners: Record<string, string>;4  dataSources: string[];5  mutationPoints: string[];6  duplicatePatterns: string[];7  riskyModules: string[];8};

2. Component tekrarını görsel benzerlikten değil sorumluluktan çözmek

AI araçları aynı problemi farklı ekranlarda yeniden çözmeye eğilimlidir. Benzer görünen üç kartı tek dev component altında birleştirmek de yanlış olabilir. Önce ortak sorumluluğu ararım: veri gösterimi mi, etkileşim mi, durum yönetimi mi? Ortak olan davranışı çıkarır, ekranın bağlama özel tarafını dışarıda bırakırım.

3. State sahipliğini tekilleştirmek

Prototiplerde aynı veri URL state, component state, context ve remote cache içinde aynı anda tutulabilir. Bu yapı ilk başta hızlıdır; sonra 'hangi değer doğru?' sorusunu doğurur. Her state için tek bir sahip belirlerim: server state cache'de, form draft'ı local state'te, kalıcı kullanıcı tercihi storage veya backend'de, route'a ait seçim URL'de yaşar.

4. Veri erişimini UI'dan ayırmak

Component'in içinde doğrudan Supabase, fetch veya SDK çağrısı varsa UI; auth, veri şekli, hata modeli ve network davranışının tamamını bilmek zorunda kalır. Production'a geçerken bu sınırı servis/query katmanına taşırım. UI yalnızca ne istediğini söyler; verinin nereden ve nasıl geldiğini bilmez.

1// UI2const { data, status } = useProject(projectId);3
4// data boundary5export async function getProject(id: string): Promise<Project> {6  const row = await projectRepository.findById(id);7  return mapProject(row);8}

5. TypeScript'i susturmak yerine sözleşme olarak kullanmak

Prototipte any ve geniş optional tipler akışı hızlandırabilir. Production'da ise tiplerin görevi editörü memnun etmek değil, sistem sınırlarını belgelemektir. API response, domain entity ve UI view model aynı tip olmak zorunda değildir. Bu ayrım özellikle migration, feature flag ve geriye dönük uyumlulukta büyük fark yaratır.

6. Büyük rewrite yerine strangler refactor

Çalışan prototipi tek seferde yeniden yazmak çoğu solo ürün için gereksiz risk üretir. Önce yeni kuralları bir modülde uygular, eski akış ile arasında adapter kurar, davranışı doğrular ve sonra sıradaki modüle geçerim. Böylece ürün çalışmaya devam ederken mimari kademeli olarak değişir.

• Kritik kullanıcı akışlarını önce test veya gözlemlenebilir davranışla sabitle.
• En çok değişen veya en fazla hata üreten modülü seç.
• State ve data boundary'lerini tanımla.
• Yeni modülü eski davranışın arkasına yerleştir.
• Eski yolu kaldırmadan önce production davranışını karşılaştır.
• Her adımda bundle, network ve error yüzeyini yeniden ölç.

7. Ne zaman refactor tamamlanmış sayılır?

Dosya sayısı azaldığında değil; yeni bir özellik eklemek için beş farklı state kaynağını anlamak gerekmiyorsa, kritik mutation'ın nerede olduğu belliyse, veri erişimi tekrar etmiyorsa ve bir agent'a modülün sınırlarını kısa biçimde anlatabiliyorsam refactor amacına ulaşmıştır.

1const modularEnough =2  singleStateOwnership &&3  explicitDataBoundaries &&4  typedContracts &&5  predictableSideEffects &&6  replaceableModules;