Code Review’ın Sırları: Daha İyi Kod, Daha İyi Takım
Code review sürecini kişisel marka ve takım başarısına dönüştürmek!
Code Review, yazılım geliştirme sürecinin olmazsa olmazıdır. Buna rağmen birçok takımda hâlâ ya hiç uygulanmıyor ya da yeterince olgun bir seviyede değil. Bunun en büyük nedeni ise code review denilince herkesin aklına farklı önceliklerin gelmesi.
Üstelik code review her şirketin, hatta her takımın “yoğurt yiyişine” göre değişebilir. Bu gayet normal. Bir developer yeni bir şirkete başladığında öğrenmesi gereken ilk şeylerden biri de şirketin code review stratejisidir.
Diğer taraftan iyi bir code review süreci, hem kodun yazarı hem de reviewer hakkında çok şey söyler. Bana kalırsa bu, kişisel markanın da bir parçasıdır. Bir kod parçasını review’a açarken veya bir kodu incelerken takip ettiğiniz strateji, kullandığınız iletişim dili ve önem verdiğiniz kriterler zamanla şirket içindeki itibarınızı olumlu ya da olumsuz etkiler. Dolayısıyla code review süreçleri yalnızca şirketin değil, her developer’ın da meselesidir.
Bu makalede:
Neden code review yapıyoruz?
Code review’ın asıl major faydası nerede?
Code review süreçlerindeki iyi pratikler ve günahlar
gibi konulara değinerek bir çerçeve çizmeyi ve sürdürülebilir bir yöntem önermeyi hedefliyorum.
Keyifli okumalar! ☕️
Ne için, kim için Code Review?
Code review yapmanın öncelikli hedefi codebase’in sağlığını uzun yıllar koruyabilmesini sağlamaktır. Yazının ilerleyen noktalarında pek çok yan faydadan bahsedeceğiz ama asıl major fayda şudur: yaşayan bir organizma olan kodun yaşam süresini artırmak. Ömründen nefes çalmak yerine, ömrüne ömür katmaktır.
Code Review Yaparken Neleri Kontrol Etmeliyiz?
Bence en büyük kafa karışıklığı tam da burada başlıyor. Bir developer’dan review istediğinizde, %80 oranında şu tip yorumlarla karşılaşırsınız:
Burada fazladan bir boşluk kalmış.
Değişken isminde typo var.
Değişken ismini değiştirebiliriz.
Bunlar kıymetsiz değil, önceliksiz. Çünkü bu tür yorumları pekâlâ CI/CD pipeline’a entegre edilmiş bir linter tool ile alabilirsiniz. Üstelik bir insan gözünden çok daha hızlı ve hatasız.
Dolayısıyla code review süreçlerinde ilk yapılması gereken şey: bir tool’a adreslenebilecek her şeyi otomatize etmek. Çünkü kodun review’da beklediği süre şirketler için ciddi bir maliyettir. Bu yüzden birçok şirket bu süreyi ölçer ve düşürmek için ekstra süreçler geliştirir.
Peki o halde bir code reviewer neleri kontrol etmeli?
Yukarıdaki code review piramidinde en altta review edilmesi en kıymetli kısımlar yer alırken, en tepede gerekli ama düşük öncelikli noktalar bulunur. Kod stili ve testlerin kontrolü rahatlıkla otomatize edilebilecek alanlardır ve insan review’una en az ihtiyaç duyulan kısımlardır.
Piramitte aşağıdan yukarıya doğru çıkıldıkça code review’ın etkisi giderek azalır. Bu yüzden bir kod parçasını incelerken önceliğimiz, tasarım ve işlevsellik; sonrasında ise kod implementasyonu olmalıdır.
Şimdi piramidin her katmanının değerine daha yakından bakalım.
Tasarım ve İşlevsellik
Yapılan değişiklik projenin genel mimarisine sadık kalıyor mu? Takımın belirlediği best practice’ler ihlal edilmiş mi?
Katmanlar arasında veri taşınırken bir kural ihlali var mı?
Projeye dahil edilmemesi gereken bir kütüphane eklenmiş mi?
Paketler doğru katmana mı dahil edilmiş?
OOP, SOLID, DRY, KISS, YAGNI gibi bilinen pratikler gözetilmiş mi?
Çözüm low coupled ve high cohesive’ mi?
Çözüm yeterince modüler mi?
Feature/Code Implementasyonu
Eklenen kodun niyeti ve implementasyonu doğru mu?
Client’a veri dönen bir endpoint gereksiz data expose ediyor mu?
API imzası standartlara uygun mu?
Authorizer doğru konfigüre edilmiş mi?
Fazladan kod yazılmış mı ya da performans problemi var mı?
Hata senaryoları yeterince iyi handle edilmiş mi?
Çözüm yeterince basit mi yoksa gereksiz bir complexity artışına neden oluyor mu
Bu noktada kodun işlevselliğini gerçekten challenge etmek gerekir.
Test
Feature veya kod parçası beklendiği gibi çalışıyor mu?
Eksik unit veya integration test var mı?
Testler happy path kadar worst case’leri de kapsıyor mu?
Eklenen kod mevcut testleri kırıyor mu?
Amaç, takımın test yaklaşımına katkı sağlamak ve var olan testlerin sağlamlığını garanti altına almak.
Dokümantasyon
PR description yeterince açıklayıcı mı?
PR standartlara uygun açılmış mı?
Readme veya external dokümantasyon araçları güncel mi?
Kod Stili
Proje standartlarına uyulmuş mu?
Değişken isimlendirmeleri doğru mu?
Okunabilirlik tatmin edici mi?
Bunlar işlevsellikten çok okunabilirlik ve sürdürülebilirlik için önemlidir.
Code Review Süreçlerinde İyi Pratikler
Kodun Yazarı için
Öncelikle kendin review et
Kodu yazarken “oldukça iyi” görünen şeyler, biraz uzaktan ve bütün olarak bakıldığında problemli olabilir. Üstelik direkt koda bakmak ile PR üzerinden bakmak arasında fark var. İnsan, reviewer psikolojisine girdiğinde koda daha eleştirel bakabiliyor. Bu pratik, reviewer’ın ilk bakışta hemen görebileceği sorunları önden yakalamanı sağlar. Hem de düşündüğünden çok daha kısa sürer.
Kısa ve anlaşılır PR açıklamaları yaz
PR açıklamaları genelde sadece reviewer için yazılıyormuş gibi görülür. Oysa bence bu, unit test yazmaya çok benzer: yazdığın kod ya da geliştirdiğin iş üzerinden yalın ve derinlemesine düşünme fırsatıdır.
Özet ve anlaşılır açıklama yazmak zordur çünkü odaklanma gerektirir. Ama odaklandığında, açıklamayı yazarken bile kodundaki pürüzleri fark edebilirsin. Tam tersine, uzun, detaylı ve tekrar eden açıklamalar ne sana fayda sağlar ne de reviewer gözünde olumlu bir his bırakır.
Koda gelen yorumları içtenlikle değerlendir
Burada en sık görülen davranış pattern’i fazla korumacı ve ofansif olmaktır. Gelen yorumu koduna yapılan kişisel bir eleştiri gibi değil, codebase’i ileri götürecek bir öneri gibi algıla. İçtenlikle değerlendir; ikna olmuyorsan argümanlarınla tartış. Ama sadece “yorum geldi” diye de kodunu değiştirmek zorunda değilsin. Code review’ın en büyük değeri burada yatar: fikir çarpıştırarak daha iyisini bulmak.
PR’ı çok büyütmeden review iste
En kaliteli ve verimli review süreçleri küçük PR’larda yaşanır. Çünkü insan beyni aynı anda çok fazla bilgiyi sağlıklı şekilde işleyemez. Satır satır kodu okumak, anlamak ve yorumlamak yorucudur. Eğer gerçekten iyi bir review almak istiyorsan, reviewer’a yardımcı ol ve PR’ını küçük tut.
Kompleks bir işe başlamadan önce takım ile el sıkış
Birden fazla şekilde yapılabilecek bir iş varsa ve review aşamasında sürtünme çıkacağını öngörüyorsan, önce takım arkadaşlarınla tartış. En iyi yönteme beraber karar verin. Bu, seni fazladan iş yapmaktan kurtarır ve tek başına alacağın karara göre daha iyi bir çıktı doğurur. Böylece review aşamasında geri bildirimler daha çok detaylara odaklanır.
Approve değil, review iste 🙂
Bazı developer’lar PR açarken “Bir approve alabilir miyim?” diye soruyor. Bu bilinçli mi, bilinçsiz mi yoksa sadece wording mi bilinmez 🙂 Ama unutma: review süreci onay almak için değil, daha iyisini bulmak için yapılır. “Approve isterim” dediğinde bu hem antipatik olur hem de gereksiz bir gerginlik yaratır. Adı üstünde “Code Review”, “Code Approve” değil. Approve ve Change Request ise sadece sürecin çıktılarıdır.
Reviewer için
Kodu IDE’den açarak review et
Çoğu zaman review süreci, doğrudan GitHub UI üzerinden sadece değişen satırlara bakılarak yapılır. Bu çok yaygın bir alışkanlıktır. Ama bu şekilde yapılan review, statik kod analizi seviyesini geçemez.
Code review piramidinin en kritik faydaları — tasarım & işlevsellik ile feature implementasyonu — böylece gözden kaçar. Bunun yerine PR’ın açıldığı source branch’i localde checkout et ve değişikliklerin kodun geneline etkisine bak.
Code review yaparken acele etme
Çoğu developer için review, kod yazmaktan daha “sıkıcı” bir iştir. Bu yüzden çoğunlukla hızlıca değişikliklere göz atıp approve verme eğilimi vardır. Oysa satır satır okuyup anlamaya çalıştığında review’ın da kod yazmak kadar incelik ve dikkat gerektirdiğini fark edersin.
Zaman ayırarak yaptığında, takım içinde iyi bir reviewer olarak bilinir ve saygı kazanırsın. İnsanlar senden review almak istediğinde rahatlar çünkü senin gözünden kaçmayacağına güvenirler. Bu güven, zamanla ekibin kültürünü de güçlendirir.
Review’ı kodun yazarı ile yapma
Bazen kompleks işlerde hız kazanmak için mob review yapılır: yani yazar ve reviewer’lar birlikte koda bakar. Bu faydalı olsa da, yazarın kendi düşünce şekline göre seni yönlendirmesi kaçınılmazdır. Böylece major fayda kaçabilir.
Eğer mob review yaptıysanız bile sonrasında kendi başına bir kez daha okumayı iste. Emin ol, tek başına bakarken mob review’da gözünden kaçan pek çok şeyi fark edeceksin.
Yorum yazarken nazik ol
Bir developer’ın kodunu açması, aslında en kırılgan yanını göstermesi gibidir. Çünkü kod, kişinin düşünme biçimini, analitik kapasitesini ve teknik becerisini ortaya koyar — aynı zamanda eksiklerini de.
O yüzden yorum yaparken kelimeleri özenle seç. Kapsayıcı ve kişisel olmayan bir dil kullan. Zaten doğası gereği gerilime açık olan code review sürecinde, nezaket göstererek kaybedeceğin hiçbir şey yok.
Mükemmeli arama
Her zaman daha iyisi vardır, ama her review sonsuza kadar devam etmemeli. “Yeterince iyi” genellikle yeterlidir. Eksiklik varsa ama feature’a etkisi yoksa, yorum olarak bırakabilir ve PR’ı onaylayabilirsin. Bu yaklaşım, kod sahibinde takdir uyandırır. Çoğu zaman o “opsiyonel” dediğin önerileri bile uygulamaya çalışacaktır. Onay vermeyerek dayatmak yerine, geliştiriciye inisiyatif alanı bırakmak daha hızlı ve sağlıklı bir süreç doğurur.
Checklist’lerden faydalan
Şart değildir ama ekip olarak ortak bir code review checklist oluşturmak faydalıdır. Bu, reviewer olarak senin hiçbir şeyi kaçırmamanı sağlar. Aynı zamanda geliştiriciler için de bir güvence oluşturur; çünkü PR açmadan önce checklist üzerinden geçip eksiklerini tamamlayabilirler.
Özetle
Code review, sadece bir süreç değil; hem kodun hem de developer’ın gelişimi için kritik bir araçtır. Bu süreç, kodun ömrünü uzatırken, takım içindeki iletişimi güçlendirir ve kişisel markanıza katkı sağlar.
Unutmayın: iyi bir code review, detaylı ama odaklıdır; hızlı ama bilinçlidir; eleştirel ama naziktir. Kodunuzu, PR açıklamalarınızı ve yorumlarınızı bu bakış açısıyla yönettiğinizde, hem siz hem de takımınız bundan kazanır.
Son olarak, code review’da mükemmeli aramak yerine “yeterince iyi”yi bilerek ilerlemek, sürekliliği ve verimliliği korumanın anahtarıdır. Küçük PR’lar, net açıklamalar, nazik yorumlar ve checklist’ler ile sürdürülebilir bir code review kültürü oluşturabilirsiniz.
Buraya kadar benimle kalıp okuduğun için tebrikler!
Eğer ilham verici ya da düşündürücü bulduysan, aşağıdaki ❤️ ikonuna tıklayabilir, ilgisini çekeceğini düşündüğün biriyle paylaşabilir ve gelecek sayılardan haberdar olmak için abone olabilirsin.
👋 Bağlantıda kalalım! Beni LinkedIn’de bulabilirsin.