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üzlerindeler: elinde güvenilmez anlatılar var, güvenilir bir yeniden kurulum istiyorsun.

Kaynak eleştirisi nedir?

yüzyılda Leopold von Ranke çevresinde olgunlaşan Quellenkritik (kaynak eleştirisi), tarihçiliğin temel yöntemi haline geldi. İki aşaması var: dış eleştiri (belge otantik mi — kim, ne zaman yazdı, sonradan değiştirildi mi) ve iç eleştiri (belge söylediği şeyde inanılır mı — yazarın çıkarı, bakış açısı, bilgiye erişimi neydi).

Ranke’nin meşhur hedefi şuydu:

Olanın, gerçekte nasıl olduğunu göstermek.

Naif bir tarafsızlık ideali gibi okunsa da, özünde sağlam bir ilkeyi barındırır: anlatı ile iz arasında ayrım yapmak, izi her defasında yeniden sorgulamak.

Kod incelemesi aynı soruları sorar

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ı)	İssue 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

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

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

İki zanaatin de vardığı yer aynı: “güven, ama doğrula” değil, “güvenmek için önce izin 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.