Bir ürünün mimarisi genelde bir günde bozulmaz. Her sprint küçük bir kısayol, her deadline küçük bir teknik borç. Bir gün bakıyorsunuz ki deploy 40 dakika, bug fix 3 gün, yeni özellik 6 hafta. Sessiz sessiz gelir.
Danışmanlık projelerinde ilk hafta kod tabanının “ne kadar bozulduğunu” ölçmeye çalışırım. Aşağıdaki 5 sinyal herhangi bir ürün kodu için erken uyarı işaretleri.
1. Deploy süresi her ay uzuyor
6 ay önce 4 dakikada deploy oluyordu, şimdi 12 dakika. Genelde şu sebeplerden olur:
- Build artık her şeyi rebuild ediyor, incremental cache çalışmıyor
- Test suite’e feature eklendikçe paralelleştirmeden toplam süre uzuyor
- Docker image giderek şişiyor (dev bağımlılıkları production’a sızmış)
- Database migration’ları çok yavaş (indexler yanlış)
Takip etmek basit: CI’daki son 30 build’in süresinin ortalamasını haftalık grafikle. Yavaş yavaş çıkıyorsa düzeltme zamanı. Deploy yavaşlığı direkt teslim hızını öldürür, çünkü geliştiriciler daha seyrek deploy eder, batch’ler büyür, risk artar.
2. Aynı bug’lar farklı kılıklarda gelmeye başladı
Ağustos’ta “para birimi hatası”, Ekim’de “fatura hesabında yuvarlatma”, Şubat’ta “vergi tutarı yanlış”. Bunlar farklı bug’lar gibi görünüyor ama hepsi aynı kök sebepten: projeye Money veya Decimal wrapper’ı eklemediysen, sayıların nasıl temsil edildiği her yerde tekrar tekrar dert oluyor.
Bu pattern’ı fark etmek için: bug tracker’ına etiketler düşürün. “para”, “tarih”, “zaman-dilimi”, “yetki” gibi. 6 ayda aynı etikette 5+ ticket varsa, orada bir abstraction eksik.
Fix: kök sebebi bulduğunda, sadece o bug’ı kapatma, o problem sınıfının bir daha yaşanmayacağı bir abstraction kur. Benim kural: aynı tip bug’ı 3. kez gördüğümde refactor’ü bug fix’le aynı sprint’e yazıyorum.
3. Yeni geliştirici onboarding’i 2 hafta sürüyor
Sağlıklı bir proje yeni birinin ilk commit’i 2-3 günde atmasına izin vermelidir. 2 hafta oluyorsa mimari bozulmaya başlamış demektir:
- Local dev ortamı kurulmuyor (undocumented step’ler, env variable’lar)
- Kod haritası yok, yeni kişi “X özelliği nerede işleniyor?” sorusunun cevabını 30 dakikada bulamıyor
- Test çalıştırmak için “ayrıca bu servisi aç, bu docker’ı çalıştır” gerekiyor
- Code review’lar 2 günde bir yapılıyor, geri bildirim döngüsü uzun
Bunu sorgulamak için basit bir metrik: son 3 yeni geliştiricinin ilk pull request’i kaç günde geldi? Artıyorsa sinyal var.
4. “Bu kısıma kimse dokunmak istemiyor”
Her ürünün bir “ürkütücü kısmı” vardır. Ödeme akışı. Vergi hesabı. Rapor motoru. “Ben o kısıma bakmam, bozulacağından korkuyorum” demek hafiflikle söyleniyor ama aslında ürün için ciddi risk:
- O modülü sadece 1-2 geliştirici biliyor, bus factor riski
- O modülü kimse test etmiyor (refactor korkusu)
- O modülün tedarik zinciri (bağımlılıkları) hiç güncellenmiyor
Fix: o modüle 4 hafta ver, yeni testler yaz, dokümante et, bir daha 2 kişi paralelden aynı sisteme dokunsun. Pahalı görünüyor ama o modül çöktüğünde crisis response’u haftalarca sürer.
5. Database query’lerinin P99’u haftalık kötüleşiyor
Performans tarafında en dürüst metrik: P99 query latency. Ortalama “250ms” diyebilirsiniz ama P99 “5 saniye” ise kullanıcıların %1’i 5 saniye bekliyor, ve onlar genelde sizin en değerli müşterileriniz, en çok veriye sahip olanlar.
Görmezden gelme sinyalleri:
- Table scan’ler index kullanmadan yapılıyor (N+1 query problemi farklı bir şey)
- Slow query log’u boş görünüyor çünkü threshold yanlış ayarlı
- Otomatik VACUUM tamamlanmıyor (PostgreSQL’de özellikle)
- ORM’in oluşturduğu query’lerin hiçbiri optimize edilmedi
Haftalık bir dashboard kurun: P50, P95, P99 query latency, en yavaş 10 query. Her haftalık sprint retrospective’inde bakın. Sayı kötüleşiyorsa 1 günlüğüne bir geliştirici ayırıp inceleyin.
Sonuç
Mimari sağlık “hissedilen” bir şey değil. Ölçülür. Bu 5 metrik benim danışmanlık projelerinde ilk bakmak istediklerim. İkisi bile kötü görünüyorsa, ürünün başı dertte demektir.
İyi haber: bu metriklerin hepsi düzeltilebilir. Ama önce ölçmek lazım.