# Yabancı bir kod tabanını devralmak

> Hiç bilmediğiniz bir kod tabanına hızlı ve sağlam biçimde hâkim olmanın yolu: erken refactor değil, önce anlamak.

- Yayın: 2026-09-06
- Kategori: Günlük
- Etiketler: Kariyer
- Okuma süresi: 2 dk okuma
- Kaynak: https://www.muhammetsafak.com.tr/blog/yabanci-bir-kod-tabanini-devralmak/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
Bir geliştiricinin işinin büyük bölümü, kendi yazmadığı kodun içinde geçer. Yeni bir işe başlarsınız, devredilen bir projeyi alırsınız ya da yıllar önce kendi yazdığınız ama artık yabancılaştığınız bir koda dönersiniz. [Sıfırdan yazmak istisnadır](/blog/sifirdan-hizli-mevcut-sistemde-yavas/); asıl beceri, var olan bir kod tabanına hızla ve sağlam biçimde hâkim olmaktır. Yıllar içinde bunun için oturmuş bir düzenim oldu.

## Önce çalıştırın

İlk yaptığım şey kodu okumak değil, **çalıştırmak.** Projeyi yerel makinemde ayağa kaldırana kadar onun hakkında hiçbir şey bildiğimi varsaymıyorum.

Bu adım çoğu zaman tek başına öğreticidir. Kurulumda hangi adımların belgelenmediğini, hangi gizli bağımlılıkların olduğunu, ortamın ne kadar kırılgan olduğunu daha ilk saatte görürsünüz. Bir projenin sağlığı hakkındaki ilk dürüst sinyal, "kurulumu ne kadar sürdü?" sorusunun yanıtıdır.

## Testleri okuyun

Dokümantasyon eskir; yorumlar yalan söyleyebilir; ama testler çalışıyorsa, sistemin gerçekte ne yaptığını anlatır. Bir kod tabanını tanımak için testlerden daha dürüst bir kaynak az bulunur.

Testler bana iki şey veriyor: sistemin en kritik davranışlarının hangileri olduğu ve bir şeyi değiştirdiğimde neyin beni uyaracağı. Test yoksa, bu da bir bilgidir — değişiklik yaparken çok daha temkinli olmam gerektiğini en baştan öğrenmiş olurum.

## Tek bir akışı uçtan uca izleyin

Bütün kodu okumaya çalışmak boğucu ve verimsiz. Bunun yerine **tek bir isteği** seçip onu uçtan uca takip ediyorum: giriş noktasından başlayıp veritabanına ve geri dönüş yanıtına kadar.

Bu tek dikey kesit, kod tabanının nasıl düşündüğünü gösterir — katmanları nasıl ayırdığını, adlandırma alışkanlıklarını, kararların nerede verildiğini. Bir akışı gerçekten anladığınızda, ikincisini anlamak çok daha hızlıdır; çünkü artık deseni biliyorsunuzdur.

## Erken refactor etmeyin

En sık yaptığım gençlik hatası buydu: yabancı bir koda bakıp "bu yanlış yazılmış" deyip hemen düzeltmeye girişmek. Yıllar bana şunu öğretti — tuhaf görünen kodun çoğu, görmediğim bir kısıtın izidir. O acayip `if`, bir zamanlar gerçek bir hatayı kapatmıştır.

Bu yüzden ilk birkaç hafta neredeyse hiç refactor yapmıyorum. Önce kodun *neden* böyle olduğunu anlıyorum. Bir şeyi değiştirme hakkını, ancak onu neden değiştirmemem gerekebileceğini de gördükten sonra kazanıyorum.

## İnsanlar ve git geçmişi de birer kaynaktır

Kodun kendisi tek bilgi kaynağı değil. İki kaynağı daha düzenli kullanmayı öğrendim.

Birincisi, git geçmişi. Tuhaf görünen bir satırla karşılaştığımda, o satırın hangi commit'le geldiğine ve o commit'in mesajına bakıyorum. Çoğu zaman "şu hatayı düzeltir" diyen bir mesaj, o acayip kodun neden orada olduğunu tek cümlede açıklıyor. Kod ne yaptığını söyler; git geçmişi neden yaptığını.

İkincisi, insanlar. Projeyi daha önce bilen biri varsa, ona soracağım soruları biriktiriyorum — tek tek değil, toplu olarak. "Bu modül neden ayrı?" gibi bir soru, bazen yarım günlük okumayla bulamayacağım bir bağlamı bir dakikada veriyor. Yabancı bir koda hâkim olmak yalnız yapılan bir iş değil; doğru soruları doğru kişiye sormayı da içeriyor.

## Özet

Yabancı bir kod tabanını devralmak bir zekâ sınavı değil, bir sabır meselesidir: çalıştır, testleri oku, bir akışı izle, erken dokunma. Hızlı görünen — hemen düzeltmeye girişmek — aslında en yavaş yoldur; çünkü anlamadan yapılan değişiklik, çoğu zaman geri alınması gereken bir değişikliktir.