Kaynak Eleştirisi ve Kod İncelemesi: Aynı Zanaatın İki Yüzü

Yazılım dünyasında hata ayıklama (debugging) denince akla gelen manzara hep aynıdır: ekranda akan log kayıtlarından “gerçekte ne olduğunu” kurmaya çalışan biri. Bu manzara, bir tarihçinin belge okurken takındığı tavırla şaşırtıcı derecede benziyor. İkisi de geçmişin izlerinden “gerçekte ne olduğunu” yeniden kurmaya çalışıyor. İkisi de izlerin güvenilirliğiyle — kim bıraktı, ne zaman, hangi amaçla — baş etmek zorunda.

Bu benzerlik tesadüf değil. İki disiplin de aynı temel problemin farklı yüzleri: elinde güvenilmez anlatılar var, güvenilir bir yeniden kurulum istiyorsun.

Kaynak eleştirisi nedir?

19. yüzyılda Leopold von Ranke, Quellenkritik (kaynak eleştirisi) yöntemini tarihçiliğin merkezine koydu. Yüzyılın sonunda Ernst Bernheim (1889) ile Langlois ve Seignobos (1898), bu yöntemi el kitaplarında iki aşamalı bir sisteme dönüştürdüler. Birinci aşama dış eleştiridir: Belge sahici mi, kim ve ne zaman yazdı, sonradan değiştirildi mi? İkinci aşama iç eleştiridir: Belgenin söyledikleri güvenilir mi, yazarın çıkarı, bakış açısı ve bilgiye erişimi neydi?

Ranke, 1824’te yayımlanan ilk kitabının önsözünde, tarihe geçmişi yargılama görevi yükleyenlere karşı daha mütevazı bir amaç koyar:

(Bu çalışma) yalnızca, gerçekte nasıl olduğunu göstermek istiyor.¹

Bu cümle saf bir tarafsızlık ideali gibi okunabilir. Ama özünde sağlam bir ilke taşır: Anlatı ile izi birbirinden ayırmak ve izi her seferinde yeniden sorgulamak.

Kod incelemesi aynı soruları sorar

Kod incelemesi ile kaynak eleştirisi arasında nasıl bir benzerlik var?

Bir çekme isteğine (pull request) baktığınızda yaptığınız şey dış ve iç eleştiriden farklı değil:

Kaynak eleştirisinde soru	Kod incelemesindeki karşılığı
Belgeyi kim yazdı?	git blame, PR yazarı
Ne zaman yazıldı?	Commit tarihi, o günkü mimari bağlam
Neden yazıldı? (yazarın çıkarı)	Issue numarası, commit mesajı
Orijinal mi, sonradan değişti mi?	Rebase geçmişi, cherry-pick izleri
Bağlamı neydi?	Mimari karar kayıtları, RFC’ler, tasarım belgeleri

Bir kod satırının ne yaptığını anlamak çoğu zaman kolaydır; neden öyle yazıldığını anlamak içinse belgeye, geçmişe ve yazarın niyetine inmek gerekir. “Çalışıyor ama neden böyle?” sorusu, tarihçinin “kaynak bunu neden böyle anlatıyor?” sorusuyla aynı yerden doğar.

Birincil kaynak, ikincil kaynak

Birincil ve ikincil kaynak arasındaki fark nedir?

Tarihçilikte ayrım nettir: birincil kaynak olayın çağından kalma izdir (belge, mektup, kayıt); ikincil kaynak ise sonradan o izler üzerine yazılmış yorumdur. Yazılımdaki karşılığı doğrudan kod ve onun üzerine yazılan her şey — dokümantasyon, blog yazıları, Stack Overflow cevapları.

“Eski dokümantasyon” sorununun özü de budur: ikincil kaynak birincille çeliştiğinde tarihçi ne yapıyorsa mühendis de onu yapar — birincile döner. Dokümantasyon bir yorumdur; kod ise tanıklıktır. (Kod da yalan söyleyebilir elbette — o zaman çalıştırırsınız. Tarihçinin deney karşılığı budur: belgenin söylediğini, birleştirilebildiği diğer izlerle çapraz okumak.)

Loglar günümüze kalan kroniklerdir

Sunucu kayıtları neden bir kronik gibi okunabilir?

Bir sunucunun log kayıtları, tam anlamıyla bir kroniktir: olay odaklı, eksik, yanlı, çoğu kez olaydan sonra derlenmiş. Hata ayıklama ise kaynak eleştirmenin ta kendisi — log satırının neyi kaydettiğini, neyi kaydetmediğini (yoksunluklar sessiz kalır!) ve kaydın hangi koşullarda üretildiğini düşünerek ilerlersiniz.

Gözlemlenebilirlik (observability) araçlarına harcanan emeğin özünde bir arşiv bilimi problemi olduğunu fark ettiğimde ürünlerdeki log stratejilerine bakışım değişti: iyi log, iyi kronik yazmak gibi — kaydeden tarafı belli, zaman damgası güvenilir, bağlamı kaybetmemiş olmalı.

Güven, ama izin okuyarak

Bir kaynağa ne zaman güvenebiliriz?

İki zanaatin de vardığı yer aynı: “güven, ama doğrula” değil, “güvenmek için önce izlerin kendisini doğrula”. Belgeye koşulsuz güvenen tarihçi, koda koşulsuz güvenen mühendis gibi yanılır; ikisi de anlatının çekimine kapılır.

Belki de bu yüzden bu iki alan birbirinden bu kadar çok şey öğrenebilir: tarihçilik, izlerin sessizliği ve yansızlığı hakkında yazılıma; yazılım, sürüm kontrolü ve yeniden üretilebilirlik hakkında tarihe bir şeyler söyler. Bu blogun da tam o sınırda durmasını istememin sebebi bu.

Dipnotlar

1. Almanca aslı: “er will bloß zeigen, wie es eigentlich gewesen.” Ranke, Geschichten der romanischen und germanischen Völker von 1494 bis 1514 kitabının 1824 tarihli ilk baskısının önsözü. ↩

Kaynakça

1. Bacchelli, A. ve Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. Proceedings of the 35th International Conference on Software Engineering (ICSE) içinde (s. 712–721). IEEE. https://doi.org/10.1109/ICSE.2013.6606617
2. Bernheim, E. (1903). Lehrbuch der historischen Methode und der Geschichtsphilosophie (Gözden geçirilmiş baskı). Duncker & Humblot. (Özgün eser 1889’da yayımlandı)
3. Grafton, A. (1997). The footnote: A curious history. Harvard University Press.
4. Langlois, C.-V. ve Seignobos, C. (1898). Introduction aux études historiques. Hachette.
5. Ranke, L. von. (1885). Geschichten der romanischen und germanischen Völker von 1494 bis 1514. Duncker & Humblot. (Özgün eser 1824’te yayımlandı)