- Codebase Drag, tüm işlerin gerekenden uzun sürmesine neden olan codebase durumudur; sprint raporlarında veya dashboard’larda görünmediği için liderliğin bunu bir "insan problemi" sanmasına yol açan bir kısır döngü yaratır
- Yıllar süren codebase audit’lerinin sonucunda aynı 5 sinyalin tekrar tekrar ortaya çıktığı görüldü ve bunları 0–2 puanla nicelleştiren bir tanı rubriği olan "codebase drag audit" önerildi
- Tahminleri şişirme, deploy korkusu, "dokunma" dosyaları, coverage yalanı ve ilk commit’e kadar geçen süre gibi 5 sinyalin tamamı codebase kalite sorunlarından kaynaklanır; insanların yetersizliğinden değil
- Deneyimli mühendisler codebase risklerini daha iyi gördükleri için daha temkinli hareket eder; bu da aslında daha yavaş göründükleri bir paradoks yaratır. Bunu yetenek sorunu sanmak ise sadece daha fazla süreç eklenmesine yol açar
- 4 puan ve üzeri, doğrudan codebase’e yatırım gerektirir; 7 puan ve üzeri ise hemen yapısal müdahale gerektiren seviyedir
Codebase Drag nedir
- Codebase Drag, codebase’in her işi gerekenden uzun sürdürmesi durumudur ve sprint raporlarında ya da dashboard’larda görünmez
- Örnek: Bir müşteri ekibi admin paneline CSV dışa aktarma özelliği eklemek için 2 mühendisin 1 haftasını harcadı — işin kendisi aslında 1 günlük işti, geri kalan zaman mevcut kodu güvenle değiştirebilmek için sistemi anlamaya gitti
- Ekip hızındaki düşüş tekrarlandığında liderlik bunu bir yetenek problemi olarak yorumlayıp organizasyon değişikliği, yeni süreçler veya kadro değişikliğiyle çözmeye çalışır; ama sıradaki ekip de aynı duvara çarpar
- Sorunun kaynağı bug’lar, eksik özellikler ya da genel anlamda söylenen teknik borç değil; doğrudan codebase’in kendisidir
5 codebase drag sinyali
1. Özür dileyen tahmin (Apology Estimate)
- Aslında 3 gün sürecek bir özellik için mühendisin 2 haftalık tahmin vermesi durumu; liderlik bunu takvimi şişirme olarak yanlış yorumlar
- Gerçekte neden, billing modülündeki bir değişikliğin notification sistemini de etkilemesi gibi modüller arası coupling ve değişikliğin nereye kadar etki edeceğinin bilinmemesidir
- hidden default scope veya derin iç içe callback’ler nedeniyle değişiklik etki alanı (blast radius) kodun yarısını okumadan öngörülemez
- Tahminler düzenli olarak beklenenden 2–3 kat uzun sürüyorsa sorun tahminleme değil, codebase maliyetidir
2. Deploy korkusu (Deploy Fear)
- Ekibin cuma günü deploy yapmaktan kaçınması ya da deploy’ları biriktirip seyrek ama büyük release’ler halinde çıkması
- Bir müşteri ekibi, 3 perşembe deploy’unun hafta sonu incident’larına yol açmasının ardından çarşambadan sonra deploy yapılmaması yönünde gayriresmî bir kural uyguluyordu
- Bunun nedenleri rollback stratejisinin olmaması, güvenilmez testler ve 45 dakikalık deploy pipeline’ıydı
- DORA ölçütlerine göre elit ekipler %5’in altında change failure rate ile gerektiğinde hemen deploy yapabilir; bu ekip ise haftada bir deploy edip endişeyle bekliyordu
3. "Şu dosyaya dokunma" dosyası (Don't Touch That File)
- Neredeyse her yerde ilk 2 gün içinde "o dosyaya dokunma" cümlesi duyulur
- Üzerinde 30
before_actionolan bir billing controller ya dagit log’un tepesinde duran ama yapısal olarak yıllardır el sürülmeyen bir model gibi
- Üzerinde 30
git log --oneline --since="2 years ago"çalıştırıldığında en çok değiştirilen dosyanın hep uyarısı yapılan dosya olması — sürekli küçük yamalar yapılıyor ama yapısal çalışma yapılmıyorsa, semptomlar tedavi edilip hastalık bırakılıyor demektir- Gerçek maliyet, o modülde olması gereken işlevlerin başka yerlere uygulanmasıdır; yeni başlayanlar ise ilk hafta içinde o dosyadan kaçınmayı öğrenir — codebase, ölü bölgelerin etrafında çarpık biçimde büyür
4. Coverage yalanı (Coverage Lie)
- %80 test coverage sağlıklı görünür; ama gerçekte neredeyse hiç bozulmayan serializer, helper ve utility testleri oranı şişirirken, parayı yöneten 3 kritik modelde hiç test olmayabilir
- Test suite’in amacı regression yakalamak yerine metriği iyi göstermek haline gelmiştir — testler geçse bile production bozulur
- CI süresi 40 dakikaya çıktığı için geliştiriciler local test çalıştırmayı bırakır → coverage sayısı iki açıdan yalan söyler: önemli yerleri kapsamıyordur ve mevcut testler bile çalıştırılmıyordur
- Asıl soru coverage yüzdesi değil, "Testler en son ne zaman production’a çıkmadan önce bir bug yakaladı?" olmalıdır
5. İlk commit’e kadar geçen süre (Time to First Commit)
- Yeni bir mühendise laptop verildikten sonra onun gerçek bir bug fix veya küçük bir özellik içeren PR açmasına kadar geçen süre
- Sağlıklı bir codebase: 1–2 gün
- Drag yaşayan bir codebase: 2 hafta veya daha fazla
- Bir müşteride geliştirme ortamını kurmak haftalar sürüyordu; düzeltmeden sonra yeni geliştiriciler ortamı 15–20 dakikada ayağa kaldırabildi
- Temel neden setup rot idi —
bin/setupscript’i son ortam değişikliğinden beri güncellenmemişti, seed data artık var olmayan tablo ve sütunlara referans veriyordu, ayrıca uygulama ayağa kalkana kadar fark edilmeyen 3 adet dokümante edilmemiş environment variable vardı - Mevcut mühendisler dokümante edilmemiş adımları zaten içselleştirdiği için, codebase’in ne kadar örtük bilgi talep ettiğini en doğru biçimde yeni başlayanlar ortaya çıkarır
Kötü bir codebase’de iyi mühendisler neden yavaş görünür
- Bu 5 sinyal birlikte çalışır ve her işe standup’ta kolayca işaret edilemeyen bir ek yük bindirir
- Önceki işinde 2 günde özellik çıkaran bir mühendisin bu codebase’de 1 hafta harcaması ve nedenini anlattığında bunun mazeret gibi duyulması tipiktir
- 2025 METR araştırması, deneyimli geliştiricilerin AI araçlarını kullanırken %19 daha yavaş olduğunu gösterdi — darboğazın yazı yazma hızı olmadığının kanıtı
- En iyi mühendisler riski daha iyi gördüğü için daha dikkatli ilerler ve daha geniş tahminler verir; daha az deneyimli mühendisler riski görmeyip daha hızlı deploy eder, sonra production incident’ı çıkar ve tüm ekip daha da temkinli hale gelir
- Bir müşteri 10 yılda 6 ekip değiştirdi, buna 2 tam devralma da dahildi — liderliğin özellik talebi → borç temizliğini atlama → kodun toparlanamaz hale gelmesi → rewrite veya microservice’e bölme önerisi → sistemin ikiye çıkıp daha da kötüleşmesi döngüsü tekrarlandı
- Liderlik hız kaybını yetenek sorunu olarak okursa, zaten sürtünmeyle boğuşan ekibe yalnızca daha fazla süreç ekleyerek durumu kötüleştirir — gerçekten işe yarayan tek müdahale, yolun kendisini düzeltmektir
Codebase drag audit: nasıl teşhis edilir
- 5 sinyalin her birini 0–2 puan arasında değerlendirin:
- 0 puan: sorun yok
- 1 puan: kısmi sorun
- 2 puan: ciddi sorun
- 4 puan ve üzeri ise, başka her şeyden önce doğrudan codebase’e yatırım yapılmalıdır
Teknik borç ekibi aşağı çektiğinde nasıl karşılık verilir
- En yüksek puanlı tek sinyalle başlayın — her şeyi aynı anda düzeltmeye çalışmayın
- Deploy korkusu 2 puansa: önce CI hızı, rollback otomasyonu ve küçük deploy birimleri iyileştirilmeli
- Özür dileyen tahmin en yüksek sorunsa: en geniş blast radius’a sahip modüllerin decoupling’i öncelik olmalı
- İlk commit süresi 2 puansa:
bin/setupdüzeltmesi ve ortam dokümantasyonuna harcanacak 1 gün, sonraki tüm işe alımlarda geri kazanılır
- Rails sürümü birkaç versiyon gerideyse, version upgrade yatırımını haklı çıkaran bir forcing function olabilir
- 2 haftalık döngülerle ölçün: en yüksek puanlı sinyali seçin → odaklı sprint yapın → somut metrikleri ölçün (deploy sıklığı, tahmin doğruluğu, ilk PR süresi vb.)
- Yatırım onayı almanın zor olmasının nedeni, yapılmadığında oluşan maliyetin görünmemesidir — "teknik borç var" demektense, "bu üç modülün coupling’i her özelliği yaklaşık iki kat yavaşlatıyor" demek çok daha ikna edicidir
- 7 puan ve üzeri, genellikle 1 haftalık bir codebase audit’i ile başlanması gereken seviyedir
5 yorum
Harbiden legacy projeler tam bir kanser
Bazıları var ki en baştan yeniden yapmak daha iyi olur
Benim hikâyem mi..?
Bakım maliyetlerini azaltma açısından gerçekten önemli bir yazı gibi görünüyor.
Bu yüzden bazı durumlarda baştan yazmak daha hızlı olabiliyor.
Kod tabanını düzenlemenin uzun vadede hızı artırmanın yolu olduğunu herkes biliyor,
ama bu, iyi beslenir, egzersiz yapar ve iyi uyursan sağlıklı olursun demek kadar genel bir laf.