Hızlı Kod Yazmanın Sistemi Yavaşlattığı Paradoks

AI kod asistanlarıyla çalışan herkes bunu bilir. Cuma öğleden sonra bir özellik talebi geliyor. Pazartesi sabahı testleri geçen çalışan bir kod var ortada. Pull request temiz, iş tarafı mutlu, öğle yemeğinden önce deployment tamamlanıyor.

Sonra üç ay sonra, hiç kimsenin görmediği bir felaket kodunu debug etmekle meşgul oluyorsun.

Hız Tuzağı

Son birkaç yılda neler değişti bunu açık: kod ucuzlaştı, ama mimari pahalı kaldı.

GitHub Copilot, Claude gibi araçlar ve boilerplate kodları soyutlayan frameworkler sayesinde geliştiriciler artık beş yıl öncesinin imkansız sayacağı hızda çalışan kod üretebiliyor. İç araçlar, bileşen kütüphaneleri ve hızlı prototipleme yaklaşımları, ekiplerin minimum engelle başlatmasını ve piyasaya sürmesini sağlıyor.

Bu gerçekten harika bir şey. Daha hızlı deneyler demek daha hızlı öğrenme demek. Hızlı iterasyon yapabilen takımlar ciddi bir rekabet avantajına sahip.

Ama bu hızın içine gizli bir maliyet yerleşmiş durumda.

Mimari Nereye Gitti?

Çalışan kod, uygun kod değildir. Bir özellik bütün testlerini geçebilir ama yine de sistem için bir risk olabilir:

• Tekrarlanan mantık modüller arasında paylaşılması gereken ama paylaşılmayan
• Belirsiz sorumluluklar birkaç dosyaya saçılmış işler
• Tutarsız kalıplar codebase'i anlamayı zorlaştıran
• Güvenlik boşlukları hız için odak kaydığı için hiç kimse tarafından yakalanmayan
• Kötü sınırlar sistemler arasında başta sorun olmasa da ölçeklenince tehlike haline gelen
• Tek seferlik bileşenler aslında tekrar kullanılabilir bir yapının parçası olması gereken
• Çıkarılması zor özellikler çünkü diğer üç sisteme dolanmış durumda

Sorun şu: bu sorunlar ortaya çıkıp görülmek için, kod zaten merge edilmiş, canlı gitmiş ve ona bağımlı iş mantığı tarafından savunuluyor.

Merge Öncesi Darboğaz

Doğal tepki code review'ı sıkılaştırmak. Mimarlar ve kıdemli mühendisleri her PR'a çektirmek. Sorunları sisteme girmeden yakalamak.

Teoride mükemmel. Uygulamada? Günlerce bekleyen PR'lar. Kod yazıldıktan sonra (ve değiştirilmesi daha zor hale geldikten sonra) yaşanan tartışmalar. Çalışan bir özelliği refactor etmesini söylendikten sonra geliştiricilerin hayal kırıklığı. Üstüne de pull request kuyruğu bir darboğaz haline geliyor ve hız kazanımını ortadan kaldırıyor.

Code review bir kalite aracı değil, bir kapıcı rolüne dönüştürülüyor.

Daha İyi Bir Yol: Sürekli Mimari

Code review'ı yavaşlatmak cevap değil. Mimarı kararların gerçekten ne zaman alındığını değiştirmek lazım.

Merge öncesinde her şeyi yakalamaya çalışmak yerine, başarılı takımlar merge sonrası mimarı geri bildirim döngüleri kuruyor:

Sistem düzeyinde inceleme: Özellikler canlı gittikten sonra birisi sistemi bütün olarak değerlendiriyor. Bu değişiklik tekrarlamamız gereken bir kalıp yarattı mı? Önemsediğimiz sınırları ihlal etti mi?

Yeniden kullanım değerlendirmesi: Tekrarlanan mantığı birleştirme fırsatları var mı? Sistem ölçeğinde ortaya çıkan kalıbı ayrı tutabilir miyiz?

Güvenlik ve varsayım kontrolleri: Kod gerçek olduğuna göre, güvenlik varsayımlarımız hâlâ geçerli mi? Tek başına ele alırken görmedik bir sınır durumu var mı?

Refactor planlama: "Sonra refactor ederiz" ancak gerçekten planlanırsa işe yarar. Refactoring'i sprit boşluklarında yapılan bir şey değil, birinci sınıf bir görev olarak gören takımlar daha sağlıklı sistemler korur.

Feature flag'ler ve geri dönüş: Flag'lerin arkasında başlat. Özellikleri kapatması kolay hale getir. Bunu daha sonra yeniden yazmak isteyebileceğin olasılığını tasarımdan itibaren düşün.

Temel içgörü: mimari bir kapı değil, sürekli bir süreçtir.

"Sonra Refactor Edelim"i Gerçekleştirmek

Ancak "sonra refactor edelim" gerçek bir taahhüt olursa işe yarar, yoksa sadece bir dilek.

Hızlı geliştirmeye rağmen sağlıklı mimarıyı koruyan takımların ortak özelliği vardır:

• Mimari işlere açık olarak zaman ayırıyor (sprint arası zamanları umarak değil)
• Sistem sağlığı metriklerini özellik hızının yanında ölçüyor
• Mimari borç kritik seviyeye ulaştığında durup yeniden yazmaya istekli
• Mimarları sadece merge öncesi değil, merge sonrası review'a dahil ediyor
• Deployment sürecini refactor'lar riskli hissettirilmeyecek kadar hızlı tutuyor

Asıl Soru

Başta soru şuydu: "Mimari nerede olmalı?"

Cevap: her yerde, ama farklı zamanlarda.

Mimari tasarım konuşmalarında olması gerekiyor (kod yazılmadan). Code review'da olması gerekiyor (bariz sorunları yakalamak için). Ama merge sonrası da olması gerekiyor, refactor'larda, sistem tasarımlarında ve takımın bir adım geri çekilerek "Bu işe yaradı ama daha iyi yapabiliriz" dediği sessiz anlar.

Modern geliştirme araçlarının hızı sorun değil. Asıl meydan okuma, o hızla ayak uydurabilen ve sistemlerimizin yapısal bütünlüğünü feda etmeyen takımlar ve süreçler kurmak.

Ekibin hâlâ bütün mimarı kaygıları PR yorumlarında yakalamaya çalışıyorsa, fizikle savaşıyorsun demektir. Kod üretim motoru artık review motorunun kaldırabileceğinden daha hızlı.

Her iki tarafı da yükseltme zamanı geldi.

Senin takımın ne yapıyor? Mimarı kararları merge öncesinde, sonrasında mı, yoksa arada bir yerde alıyor? Cevap sana hızının sürdürülebilir olup olmadığı hakkında çok şey söyleyebilir.