Kod incelemesi okuma gerektirir

• Kod incelemesi, dağıtımdan önceki biçimsel bir prosedür değil; kesinti, güvenlik sorunu ve veri silme sorumluluğunu tek bir kişiden ekip sorumluluğuna taşıyan bir süreçtir
• Daha iyi evals, testler, feature flag’ler, guardrail’ler ve observability; okunmamış kodu dağıtmanın yarattığı kaygıyı azaltmaya yönelik yanıtlar olabilir, ancak bunların incelemenin sorumluluğu dağıtma amacını kaçıran bir yaklaşım olduğu eleştiriliyor
• Okumadan onay vermeyi istemek, insanlara düşünmeden düğmeye bastırmakla aynı şeydir; bu da tüm CI kontrolleri green olan rastgele bir PR’ı birleştirme hicvi olan button roulette kavramına uzanır
• Kod incelemesi, büyük bir kod tabanının farklı bölümlerini ekip üyelerinin görmesini sağlayarak bus factor’ü düşürür ve yeni ekip üyelerinin kodu ve kod kültürünü öğrenmesine yardımcı olan bir öğrenme mekanizması işlevi görür
• Okunmamış kodun production’a alınmasını dayatmak için hata, güvenlik sorunu, downtime vb. konularda yazılı sorumluluk feragati gerektiği; ancak böyle bir feragat almanın zor olduğu sonucuna varılıyor

---

İncelemenin amacı onaydan çok sorumluluğu dağıtmaktır

• Charity Majors’ın “AI enthusiasts are in a race against time, AI skeptics are in a race against entropy” başlıklı yazısındaki “Okumadığınız kodu production’a dağıtırken rahat hissetmek için ne gerekir?” sorusu çıkış noktası olarak alınıyor
• Daha iyi evals, testler, feature flag’ler, guardrail’ler, observability, bağımlılıkların ayrıştırılması, etki alanının daraltılması ve kritik yol dışındaki küçük değişikliklerle başlama gibi yanıtların, incelemenin özünü ıskaladığı belirtiliyor
• İncelemenin amacı; kesinti, güvenlik sorunları ve yanlışlıkla veri silinmesi gibi durumların yükünü tek bir kişiye bırakmak yerine, bunu yazar ve reviewer’ların oluşturduğu ekip sorumluluğu olarak paylaşmaktır
• Eğer “okumadan onay” isteniyorsa, insanlara elle düğmeye bastırmanın gerekçesi zayıflar; bunun üzerine, tüm CI’ları green olan atanmış PR’lardan birini rastgele birleştiren button roulette hicvi ortaya çıkar

Okunmadan yapılan incelemenin kaybettirdikleri

• Kod incelemesi, ekip üyelerini kod tabanının başka bölümlerine bakmaya zorlayarak, çok büyük sistemlerde her parçayı her zaman bilmenin mümkün olmaması sorununu telafi eder
• İnceleme süreci bus factor’ü düşürür ve ekibin farklı üyelerinin kod tabanına ve kod kültürüne daha aşina hale gelmesine yardımcı olur
• Herkes okumadan onay vermeye başlarsa bu öğrenme etkisi kaybolur; bus factor yalnızca 1’e çıkmakla kalmaz, aynı zamanda üçüncü taraflara dışsallaştırılır
• Okunmamış kodu production’a dağıtma talebini kabul etmek için, bu talimatı veren kişinin hata, güvenlik sorunu, downtime vb. için yazılı sorumluluk feragati sunması gerektiği sonucuna varılıyor

[GN⁺]

Lobste.rs görüşleri

• İncelemenin amacının sorumluluğu dağıtmak olduğu iddiasına güçlü biçimde itiraz ediyorum
  main’e merge edilen kod production’ı bozarsa bunun sorumluluğu yazara aittir; bana ya da tüm ekibe değil
  Bu, bir profesyonel olarak kendi imzanızı attığınız iştir; inşaat mühendisliği P.E. lisansıyla mühürlenmiş bir köprü tasarımı insanları öldürürse, o da yine kişinin kendi işi ve sorumluluğudur
  Ekibin sorumluluğu ise geliştiriciler ve kod tabanının muhafızları olarak, kimin kodu olursa olsun production’ı bozamayacak hale getirmektir

  • main’e merge edilen kod production’ı bozarsa bunun bireysel sorumluluk olduğu düşüncesinin sağlıklı bir kültür olmadığını düşünüyorum
    main’e merge edilmiş olması, birinin bunu review ettiği, değişikliği incelediği, tasarımı tartıştığı, birkaç kez düzelttirdiği ve ardından onayladığı anlamına gelir
    Eyfel Kulesi’ni kimse tek başına inşa etmez; iş yerinde bireyi suçlamak sadece kırgınlık ve zehirli bir kültür üretir
    Eğer bu tekrar eden bir davranış örüntüsüyse, bu HR’ın ele alması gereken bir konudur
  • Reviewer hiçbir sorumluluk taşımıyorsa, bu review yokmuş gibidir
    Sorumluluk 0 ise reviewer işe yaramazdır ve review yapmanın da bir anlamı yoktur
    Sorumluluğun dağılması daha çok bir sonuçtur; asıl amaç, tek başınayken gözden kaçması kolay ama iki ya da daha fazla kişi varken kaçırılması zor olan hataları yakalamaktır
    Yine de software’de review’nun aşırı kullanıldığını ve review’nun engineering’in yerine geçemeyeceğini düşünüyorum

• “Kodu okumadan onaylama”yı “düşünmeden onaylama” ile eşitlemenin isabetli olmadığını düşünüyorum
  Örneğin programın yanında bir doğruluk ispatı olsa, PR’da tanımları ve teoremleri okuyabilseniz, CI da deterministik araçlarla program ile ispatın uyuştuğunu doğrulasa; ayrıca kontrast oranı, performans benchmark’ları ve tail latency gibi işlevsel olmayan gereksinimler de kontrol edilse; UI değişiklikleri için de prototipi kolayca kurcalayabilseniz ne olurdu
  Böyle bir dünyada kodu satır satır okumaya bugün olduğu kadar takıntılı olmamız gerekip gerekmediğinden emin değilim
  Bugün bile çoğu insan SQL yazarken query plan’ın tam olarak istediği şeyle bire bir örtüştüğünü tek tek doğrulamaz
  Bana göre asıl yazı daha çok “kelimenin tam anlamıyla kodu okumadan da deploy etmenin kabul edilebilir hissettirdiği ideal bir dünyayı tanımlayalım” ve ardından “bugünden o dünyaya nasıl yumuşak bir geçiş yapabiliriz” diye soran bir metin
  Sektörün ya da belli bir şirketin/kod tabanının o noktadan ne kadar uzakta olduğu tartışılabilir; ama o ideal dünyayı ciddiyetle hayal edersek çoğumuzun aklına birkaç ölçüt gelecektir
  Sektördeki mevcut gidişat yüzünden bunu “düşünmeden” diye algılama duygusunu anlıyorum, ama Charity’nin yazısının kastı bu değil bence

  • Asıl yazının özü, PR’da sorun yakalamaktan çok, kod tabanına aşina olmak ve sorumluluk duygusu oluşturmaktır
    Bu, testler ne kadar iyi olursa olsun kodu okumayı gerektirir
    Alice kodu ekleyip Bob review ettikten sonra Alice tatile çıkarsa, Bob’un o kısmı yeterince iyi bilmesi ve bir düzeltme ya da yeni özellik eklemesi gerektiğinde sorumluluk hissedebilmesi gerekir
    Bob sadece doğruluk ispatına kaşe basıyorsa, sonrasında o kod tabanıyla çalışmaya hazır değildir
    Commit sürecine katılmış olsa bile bilgi ya da sahiplik duygusu artmadıysa, fiilen katılmamış sayılır
  • Bu açıklama tipik bir compiler’a benziyor
    Ancak compiler deterministiktir; LLM ise potansiyel olarak şüpheli testler üreten deterministik olmayan bir araçtır
    İnsanların yazdığı talimatları ya da kodu, makinenin okuyabildiği koda veya ara temsillere çeviren programlara zaten sahibiz; üstelik bunlar üretilen sonucun girdiyle nasıl bir ilişkisi olduğunu garanti ettiği için çıktıyı ayrıca incelemeden de güvenilebilir
    Optimizasyon için bazen Godbolt gibi araçlarla compiler çıktısını okuruz, ama onun dışında buna genelde gerek yoktur
    Bunu deterministik olmayan başka bir soyutlama seviyesinde denemek kulağa makul gelebilir, ama bu yalnızca compiler’ın sağladığı doğruluk garantilerini taklit etmeye çalışmak olur ve sonunda sorun çıkarır
    Bence LLM tartışması daha temelde, mevcut deterministik programlama dillerinin yeterince ifade gücüne sahip olmaması ve araçların da yeterince etkili olmaması sorununun bir belirtisi
    LLM bunun çözümüymüş gibi hissettirebilir, ama gerçek çözüm değildir; fazlasıyla kısıtlı bir temel üzerine bir dolaylı katman ve ek performans maliyeti daha bindirmek anlamına gelir
    Bence bu, yorumlayıcının üstünde, bir de derlenmiş makine kodunun üstünde çalışan pahalı ve bug dolu bir sözde compiler’a daha çok benziyor
    Bu yüzden bunun teknik bir çıkmaz sokak olduğunu düşünüyorum
    Şirketler için kısa vadeli kâr yolu olabilir, ama software’i ya da insanların software kullanma ve üretme ilişkisini iyileştireceğine inanmıyorum
    Software, bir ürünü piyasaya sürmek için kullanılan teknikten ibaret değildir

• Kullanım amacına göre ayırarak düşünmek faydalı
  İç uygulama UI’ı için yeni JavaScript yüklemek gibi bir durumda, CSS’e kadar mutlaka bakmak gerekmediğini düşünüyorum