Code Review — 2

Merhabalar,

Code Review-1 paylaşımımda “Code Review” kavramı nedir ve neden yapıyoruz sorularını cevaplamaya çalıştım. (Code Review-1 yazısı için) Bu yazımda “Code Review” tipleri nelerdir ve daha efektif yapabilmek için nelere dikkat etmeliyiz sorularını cevaplamaya çalışacağım.

Code Review Tipleri Nelerdir?

Code Review tipleri hakkında farklı kaynaklarda farklı yaklaşımlar görebilirsiniz. Yaklaşım olarak hepsine katılmakla beraber, ben bu yazıda kendi tecrübelerimden edindiğim “Code Review” tiplerini anlatmaya çalışacağım.

1. “Online” Code Review

Bu kavram farklı kaynaklarda “Over-the-shoulder” (omuz üzerinden review) olarak da tanımlanıyor. Daha önce source control olarak SVN kullandığımız zamanlarda bu tip “Code Review” yapmayı tercih ediyorduk. SVN tek bir branch üzerinden ilerlelediği için review edilecek kod parçasını review edecek kişiye göndermek yerine iki kişiyi aynı bilgisayarda buluşturmanın daha efektif olduğunu tecrübe etmiştik.

Bu “Code Review” tipinde kodu yazan kişi ve kodu review edecek kişi (genellikle tek kişi review eder) aynı bilgisayar başına oturur. Kodu yazan kişi genel olarak kodun ne yapmaya çalıştığını (gerekirse satır-satır) review eden kişiye anlatır ve review eden kişinin sorularını cevaplandırmaya çalışır. “Code Review” sonucunda herhangi bir bulgu çıkması durumunda kodun yazarı tek başına bulguları düzelttikten sonra tekrardan kodunun review edilmesini talep eder. Bu süreç kod review sürecinden başarılı olarak geçene kadar devam eder.

Bu tip “Code Review” yaparken kodun yazarı ve review eden kişi yan yana olduğu için faydalı bir süreç yürütebilmek için kullanılan ifadelere ve ortama çok daha dikkat etmek gerekir. Önceki yazımda değindiğim gibi kodun yazarı ve kendi kodu arasındaki bağa saygı duymak ve geri bildirim verirken doğru bir üslupla geri bildirimleri vermek gerekir.

2. “Offline” Code Review

Bu tipi “Offline” olarak sınfılandırmamın sebebi, bir önceki tipte olduğu gibi kodu yazan kişi ve review eden kişinin yan yana gelmiyor olmasıdır. Source control olarak “Git” kullanmaya başladığımızdan beri bu şekilde “Code Review” yapıyoruz.

Kendi tecrübemden örnek vererek anlatayım. Herkesin yazdığı kodun en son birleştiği ve her zaman çalışır ve temiz halde tutmaya çalıştığımız “master” adı verilmiş bir branch var (Branching stratejisine göre bu değişebilir). Yeni bir özelliği geliştirmek isteyen veya bug-fix yapmak istediğimiz zaman “master” branchinin son halini alıp, onun üzerine yeni bir branch çıkıyoruz. En sonunda yeni çıkılan branch üzerinde bütün işlemler bittikten sonra kodu yazan kişi bir tool aracılığıyla (bizim için TFS) pull request talebinde bulunuyor. “Code Review” yapan kişiler de bulgularını bu tool üzerinden girip “Code Review” sürecinin statüsünü değiştirip (örneğin: Waiting for Author), kodun yazarının bulguları çözmesini bekliyor. Bütün bulgular çözüldükten sonra “Code Review” yapan kişi(ler), pull request’i onayladıktan sonra yeni yaratılan branch, “master” branch ile birleşmiş oluyor.

Review tipleri bazı kaynaklarda senkron ve asenkron diye de sınıflandırılabiliyor. O kapsamda “Offline Review” için asenkron diyebiliriz. Bu tip review sürecinde tecrübe ettiğim en önemli problem senkronizasyon problemi oluyor. Review talep eden kişi bir tool üzerinden bu işlemi yaptığı için sözlü olarak review talebini iletmediği takdirde, review başlamadığı için süreç uzayabiliyor. Tam tersi olarak da review eden kişilerin birbirinden haberi olmadığı takdirde gerektiği sayıdan fazla olacak şekilde kişi aynı kodu review edebiliyor. Bu sebeple iletişim daha yüksek olan takımların bu tip code review yapmasında fayda var diye düşünüyorum.

3. Team (Takım) Code Review

Daha önce de belirttiğim gibi yazılarımda genellikle kendi tecrübelerimi aktarmaya çalışıyorum. Bu sebeple literatürde bu tip bir “Code Review” olmasa da biz ekipçe böyle adlandırdığımız için anlatmak istiyorum. Literatürdeki bir kavrama benzetmek gerekirse “Mob Programming” kavramının review için uyarlanması diyebilirim.

Bu tip review için kodu yazan kişi veya kişiler genellikle bir toplantı odasında kodlarını büyük bir ekrana yansıtacak şekilde review eden kişilere gösteriyorlar. Genellikle kodu yazan kişiler haricindeki diğer takım üyelerinin büyük çoğunluğu “Code Review” aktivitesine katılıyor çünkü bu tip bir review yapmak için çok kritik bir kod parçası yazılması gerekiyor. Kodu yazan kişiler bütün kod mantığını ve satır satır neler yapıldığını review eden kişilere anlatıyor ve onların sorularını cevaplıyor. Review eden kişiler değişiklik talebinde bulunduğunda orada takım halinde karar verilip koda son hali verilmeye çalışılıyor. Bu tip bir review takımın bütün üyelerini blokladığı için toplantı odasından çıkıldığında kodun son hali verilmiş ve review süreci bitmiş olmalı. Aksi takdirde fayda/maliyet analizinde olumsuz noktalara doğru gidebilir.

Daha efektif Code Review nasıl yapılır?

Çoğu zaman “Code Review” aktivitesinin hakkı tam olarak verilemese de aslında bu aktivite çok yoğun ve konsantrasyon gerektiren bir aktivite.

1. Bu sebeple belirli bir zaman ayırarak yapılmalı ve bu zamanı iyi kullanabilmek için de review edilecek kodun belli bir uzunluğu geçmemesine dikkat edilmeli. Linkini paylaştığım kaynakta bu sınırlar code review süresi olarak azami 90 dakika, review edilecek satır sayısı olarak da maximum 200–400 satır olarak belirlenmiş. (Code Review Best Practices) Bu sınırlar aşıldıkça “Code Review” kalitesinin düştüğü göz ardı edilmemeli.
2. “Code Review” yapılırken kodu online bir tool aracılığı ile değil kullandığınız IDE aracılığıyla review etmenizde fayda var. Kendi ortamımdan örnek vermek gerekirse; TFS online tool üzerinden review yapıldığında sadece değişiklik olan satırlar veya sınıflar üzerine odaklanıldığında diğer sınıflarla ilişkiler gibi önemli noktalar kaçırılabiliyor. Bu sebeple ben kodu Visual Studio ortamına çekip orada review yapmayı tercih ediyorum.
3. Kritik review noktaları için (döngüler,karar adımları) bütün takım üyelerinin kullanacağı bir “checklist” hazırlamanın faydalı olduğunu kanaatindeyim. Kendi takımlarımda bu checklistlerin çokça kullanıldığına şahit olamadım ama yine de faydasını savunmaya devam edeceğim. Örnek bir code review checklist için linkten faydalanılabilir ( Code Review Checklist)
4. “Code Review” daha önceki yazıda da bahsettiğim üzere aslında sosyal yetenek de gerektiren bir olgu. Bu sebeple, işin zorluğundan kurtulabilmek için review çiftleri oluşmaya başlayabiliyor. Yazılımcılar kodlarını review etmesi için daha iyi anlaştığı arkadaşlarına talep göndermeye başlayınca X kişisinin kodunu Y kişisi review eder gibi durumlar oluşabiliyor. Bu şekilde hem farklı görüş açılarını kaybetmiş oluyorsunuz hem de daha önce değindiğimiz “Collective Code Ownership” kavramı ciddi manada zarar görebiliyor.
5. Özellikle asenkron tip review aktivitelerinde bulgular yazılı yolla iletildiği için yanlış anlaşılmaya ve üslüp yanlışlarına daha açık hale gelebiliyor. Bu sebeple review eden arkadaşların bulgularını ve sonraki adımları emir kipiyle değil de bir öneri şeklinde yazmasının çok daha faydalı olduğunu düşünüyorum. (Bu maddeyi 5 sene önce okusam çok manasız gelebilirdi ama tecrübe ile sabittir diyebilirim)
6. Unit test yazmak için uygun bir kod review ediliyorsa unit test yazarak özellikle sınır koşullarını test etmek review için faydalı olabilir. (Unit test yazmak için uygun değilse başka yanlışlar da olabilir)