Yeni katıldığınız şirketin deposunda (repository) iki milyon satır kod, kırk mikroservis ve altı yıl tarih var. İlk dürtü hemen bir özellik yazmak. Oysa deneyimli geliştiriciler, ilk hafta neredeyse hiç kod yazmayan insanlardır. Fark bu: kod okumayı bir beceri olarak görmek.

Önce Haritayı Çıkart, Sonra Yürü

Büyük depoda gezinmenin ilk kuralı, dosyadan değil mimariden başlamak. Okuma sırası şöyle olmalı:

  1. README ve CONTRIBUTING — çoğu kişi atlar; ekibin sözlüğü burada.
  2. Bağımlılık dosyası — package.json, go.mod, Cargo.toml. Projenin omurgası hangi kütüphaneler?
  3. Giriş noktası — main.go, app.py, index.ts. Süreç nereden doğuyor?
  4. Konfigürasyon — docker-compose.yml, CI dosyaları. Gerçek ortam nasıl kuruluyor?

Sonra bir ağaç gibi inip soyutlama katmanlarına geçilir. İyi mimaride her katman, altındaki katmanı saran bir zarftır; haritayı üstten çizmek, kodu okurken kaybolmayı engeller.

Bir İz Bırakmadan Takip Etmek: Call Graph

Kodu okurken zihnimizde bir çağrı grafiği (call graph) kurarız: bu fonksiyon kimi çağırıyor, onu kim çağırıyor? Kâğıt üzerinde değil, araçla yapın:

# Bir sembolün tanımını bul
rg "func processPayment" --type go

# O sembolü çağıran her yeri listele
rg "processPayment\(" --type go -n

# Git ile değişiklik tarihi
git log -L :processPayment:odeme/service.go --oneline

rg (ripgrep) klasik grep'ten on kat hızlıdır ve büyük depoda arama maliyetini sıfıra indirir. git log -L ise bir fonksiyonun satırlarının tarihini çıkarır: neden böyle yazıldı sorusunun cevabı, genelde üç yıl önceki bir hata kaydındadır (issue).

Bir diğer taktik, deponun en çok değişen dosyalarını bulmak: git log --format=format: --name-only | sort | uniq -c | sort -rg | head -20. Sık değişen dosya, projenin kalp atışıdır; yeni özelliklerin yüzde doksanı o komşulukta doğar.

Küçük Düzeltmelerle Tanışmak

Büyük depoya alışmanın en hızlı yolu, önemsiz bir değişiklik yapmak: yanlış bir log mesajı, eksik bir tip tanımı, bayat bir dokümantasyon satırı. Küçük PR'lar size şunları öğretir:

  • Depo sahiplerinin kod inceleme (code review) kültürünü,
  • CI'ın gerçek beklentilerini (lint, test, imza),
  • "Bu dosya neden böyle?" sorusunu sormanın makul olduğunu.

Özellikle sonuncusu kıymetli: yıllardır orada duran garip bir soyutlama, genelde belgelenmemiş bir hata vakasının mirasıdır. Kod yazmaya başlamadan önce okuyan geliştirici, o vakayı öğrenmiş olur.

Bir de işin insani tarafı var: küçük PR'lar, depodaki isimlendirme kalıplarını da öğretir. IsAccount mu HasAccess mi, service mi manager mi? Büyük depolarda tutarlılık, yazının değil okumanın sonucudur; okumadan yazılan her yeni dosya, kalıbı biraz daha bozar.

Sonuç. Kod yazmak bir üretim eylemi; kod okumak bir keşif. Büyük depolarda hızlı olan geliştirici, en çok satırı yazan değil, en çok bağlamı çözen kişidir. Yeni işinize girdiğiniz ilk haftada bir günlük okuma sessizliği alışmak için en verimli yatırım. Sonraki hafta yazdığınız ilk satır, okuduğunuz her bin satırın karşılığıdır.