'LGTM' (Looks Good To Me) Demenin Ötesinde: Ego Savaşlarını Bitiren ve Gerçekten Değer Katan Kod Gözden Geçirme Sanatı

Giriş: En Tehlikeli Üç Harf: L-G-T-M

Saatlerce uğraştınız. Karmaşık bir problemi çözdünüz, testlerinizi yazdınız ve o tatmin edici "Commit & Push" butonuna bastınız. Pull Request'iniz (PR) hazır. Takım arkadaşlarınızın değerli geri bildirimlerini bekliyorsunuz. Ve birkaç saat sonra o bildirim geliyor: "LGTM". Yani, "Looks Good To Me" (Bana İyi Göründü).

İlk bakışta bu bir onay gibi görünebilir. Ama aslında LGTM, çoğu zaman yazılım ekiplerindeki daha derin bir sorunun, bir kültür erozyonunun habercisidir. Zaman baskısı, çatışmadan kaçınma veya ilgisizlik gibi nedenlerle yapılan yüzeysel bir geçiştirme, projenizin kalitesini yavaş yavaş kemiren bir termit gibidir. Kod gözden geçirme (Code Review), sadece bug avcılığı değildir; o, bir takımın kolektif bilgi birikimini artırdığı, standartlarını koruduğu ve kodun sahipliğini paylaştığı kutsal bir ritüeldir. Bu rehber, LGTM'nin ötesine geçip bu ritüeli nasıl bir sanata dönüştürebileceğinizi anlatacak.

Bölüm 1: Neden Yorumlarımız 'LGTM' Tuzağına Düşüyor? (Psikolojik Boyut)

Kimse kötü bir iş yapmak istemez. Peki, neden bu kadar çok zeki geliştirici, kod incelemelerini yüzeysel yorumlarla geçiştiriyor? Sebepler genellikle teknolojiyle değil, insan psikolojisiyle ilgilidir:

• Zaman Baskısı: "İnceleyecek vaktim yok, bir an önce kendi işimi bitirmeliyim." Modern yazılım geliştirmenin acımasız temposu, derinlemesine incelemeyi bir lüks olarak görmemize neden olur.
• Sosyal Çekince (Çatışma Korkusu): "Arkadaşımın koduna olumsuz yorum yaparsam gücenir mi?" ya da tam tersi, "Senior geliştiricinin kodunda bir 'hata' bulursam beni cahil sanır mı?" Kimse ekibin "sinir bozucu her şeye maydanoz olan tipi" olmak istemez.
• Belirsizlik ve Bilgi Eksikliği: "Bu kodun ne yaptığını veya dokunduğu sistemi tam anlamadım. En iyisi sessiz kalayım da başıma iş almayayım." Yetersizlik hissi, sessizliğe yol açar.
• Rol Karmaşası: Gözden geçirenin görevi nedir? Hataları bulan bir polis mi, yoksa yol gösteren bir mentor mu? Bu rolün belirsizliği, insanları en güvenli liman olan "onaylama"ya iter.

Bölüm 2: Gözden Geçirenin (Reviewer) Sorumlulukları: Dedektif Değil, Mentor Olmak

Etkili bir gözden geçirme, suçlayıcı değil, sorgulayıcıdır. Amaç parmakla göstermek değil, birlikte daha iyi bir çözüme ulaşmaktır.

İletişim Tarzınızı Değiştirin

• Emir Kipi Yerine Soru Sorun: "Bunu değiştir" demek yerine, "Bu değişikliği bu şekilde yapmanın arkasındaki düşünceyi merak ettim. Acaba şu alternatifin avantajları/dezavantajları ne olurdu?" diye sorun. Bu, bir diyalog başlatır.
• Öznel Yorumları Açıklayın: "Bu kod kötü" bir fikirdir. "Bu fonksiyonun adının, yaptığı işi tam olarak yansıtmadığını düşünüyorum. Bu durum, gelecekte kodu okuyacak kişiler için kafa karıştırıcı olabilir." ise yapıcı bir geri bildirimdir.
• Övgüyü Esirgemeyin: Gözden geçirme sadece hata bulmak değildir. "Bu karmaşık problemi çok zarif bir şekilde çözmüşsün, eline sağlık." demek, hem motivasyonu artırır hem de eleştirilerin daha kolay kabul edilmesini sağlar.

Örnek Yorumlar: Öncesi ve Sonrası

Kötü Yorum: "Bu fonksiyon çok uzun."
İyi Yorum: "Bu fonksiyon birkaç farklı sorumluluğu (veri çekme, filtreleme, formatlama) üstlenmiş gibi duruyor. Okunabilirliği artırmak ve yeniden kullanımı kolaylaştırmak için bunu iki veya üç küçük fonksiyona bölmeyi düşünebilir miyiz?"

Kötü Yorum: "Burada global değişken kullanma."
İyi Yorum: "Global değişkenler bazen beklenmedik yan etkilere yol açabiliyor. Bu state'i component'e bir prop olarak geçmek veya bir state management aracı kullanmak daha öngörülebilir bir çözüm olabilir. Ne dersin?"

Bölüm 3: Kodu Gönderenin (Author) Sorumlulukları: Savunmadan İş Birliğine

Gözden geçirme, tek taraflı bir süreç değildir. Kodun sahibi olarak sizin de sorumluluklarınız vardır.

• PR'ı Hazırlama Sanatı: Kodunuzu göndermeden önce kendiniz son bir kez gözden geçirin. Gereksiz kodları, logları temizleyin.
• Açıklayıcı PR Açıklamaları Yazın: Boş bir PR açıklaması, gözden geçirene yapılmış bir saygısızlıktır. Şablon kullanın:
  • Problem: Bu PR hangi sorunu çözüyor? (Ticket linki ekleyin)
  • Çözüm: Nasıl bir yaklaşımla çözüldü? Hangi mimari kararlar alındı?
  • Nasıl Test Edilir?: Gözden geçirenin işini kolaylaştırın. Adım adım test senaryoları sunun.
• Geri Bildirimi Kişisel Algılamayın: Yorumlar kodunuzadır, kişiliğinize değil. Amaç, kolektif olarak daha iyi bir ürün ortaya çıkarmaktır.
• Anlamadığınız Yorumu Açıklığa Kavuşturun: "Bu yorumu tam anlayamadım, bir örnekle açıklayabilir misin?" demekten çekinmeyin.

Bölüm 4: Takım Olarak Kültürü İyileştirmek İçin Somut Adımlar

Bireysel çabalar önemlidir ama kalıcı değişim takım halinde gelir.

• PR Şablonları Kullanın: Yukarıda bahsedilen "Problem, Çözüm, Nasıl Test Edilir?" yapısını tüm takım için zorunlu hale getirin.
• Küçük PR'lar Prensibi: 500 satırlık dev bir PR'ı kimse detaylı incelemek istemez. Değişikliklerinizi mantıksal olarak küçük, sindirilebilir parçalara bölün. Bir PR, ideal olarak tek bir işi yapmalıdır.
• Zaman Ayırın ve Takviminize Ekleyin: Kod gözden geçirme, "boş vakitte yapılacak" bir iş değildir. Her gün belirli bir zaman dilimini (örneğin 30 dakika) bu işe ayırın.
• Asenkron ve Senkron İletişimi Dengeleyin: Her yorum yazılı olmak zorunda değildir. Çok karmaşık bir konu üzerinde dakikalarca yazışmak yerine, "Hızlıca 5 dakika ekran paylaşarak konuşabilir miyiz?" demek, saatlerce sürecek bir yanlış anlaşılmayı önleyebilir.

Sonuç: Kodun Ötesinde, Kültürü İnşa Etmek

Etkili bir kod gözden geçirme süreci, daha az bug, daha iyi performans ve daha temiz kodla sonuçlanır. Ancak asıl ödül bu değildir. Asıl ödül; bilginin yayıldığı, kimsenin "kendi" koduna körü körüne bağlanmadığı, egoların kapıda bırakıldığı ve herkesin birbirinden bir şeyler öğrendiği bir takım kültürüdür. LGTM'den, derinlemesine ve empatik yorumlara geçiş, bir şirketin mühendislik olgunluğunu gösteren en önemli işaretlerden biridir. Bir sonraki PR'ınızda, gözden geçiren veya kodu yazan olarak bu prensipleri uygulamaya başlayarak bu değişimin bir parçası olabilirsiniz.