Code Review’da dikkat edilmesi gerekenler

Merhaba, fırsat bulamadığım için uzun süredir yazı paylaşmıyordum. Yakın bir zamanda ihtiyaç duyduğum bir alan olan code review’da dikkat edilmesi gereken hususlar ile ilgili olarak yaptığım arama sonuçlarında bulduğum bir yazıyı Türkçe’ye uyarlayarak sizinle paylaşmak istedim. Yazının orijinaline buradan ulaşabilirsiniz.

1. Tek seferde en fazla 200-400 satır kodu gözden geçirin
   Cisco’nun yaptığı bir code review çalışmasına göre, tek seferde en fazla 200 ile 400 satır arasında kodun gözden geçirilmesinin daha sağlıklı olduğu söyleniyor. Bu sayının artması durumunda bulunan hataların da azaldığı gözlemlenmiş. Yine aynı şekilde yapılan bu işlemin de 60 ile 90 dk arasında tamamlanmasının daha sağlıklı olduğu söyleniyor. Kod satırına göre hata yoğunluğunun kod satırına göre yoğunluğu da bu çalışma sonunda aşağıdaki grafikle gösterilmiş.
   
2. Saatte 300-500 satır kodu gözden geçirmeye çalışın
   Daha hızlısı ne yazık ki daha iyi olmuyor. Vaktinizi code review’da daha az geçirerek daha çok hata bulamıyorsunuz. Code review yapan kişi daha çok satır kodla vakit geçirdiği zaman, daha az satır koda verdiği önemi veremiyor. Ne kadar hızlı olması gerektiği konusunda grafiği de yine aşağıdaki gibi gösterilmiş.
   
3. Daha iyi code review için yeterli zamanı ayırın; ama 60-90 dakikadan fazla değil
   Daha iyi sonuçlar için hızlıca code review yapmamamız gerektiğinden bahsettik; ancak bunun 90 dakikadan fazla da sürmemesi gerekiyor. Genel olarak insan limitleri bir işi tek seferde 60-90 arası durmaksızın yapmaya yönelik. Bu süreden sonra code review yapan kişi yorulduğu için hata bulmayı da bırakıyor.
   Öte yandan da tek seferde en az bir satır bile olsa 5 dakika code review için zaman ayırmalısınız. Tek satırdaki bir hata bile sistemde büyük aksaklıklara yol açabilir.
4. Hedef belirleyin ve metrikleri yakalayın
   Bir süreci başlatmadan önce, takım olarak ikili gözden geçirmenin verimliliğini nasıl ölçeceğinize karar vermeli ve hedef koymalısınız. Örneğin, geliştirme sürecinde ortaya çıkan hataların geliştirmenin ilk yarısında %15 azaltılması bir hedef olabilir. Daha fazla hata temizleme iyi bir hedef değildir. Ayrıca aşağıdaki metrikleri izlemek de iyi bir çözüm olabilir:
   1. Inspection rate: Code review hızı
   2. Defect rate: Bir saatlik review’da bulunan hata sayısı
   3. Defect density: Kod satır sayısına göre hata oranı
5. Code review öncesi annotation kullanımı
   Annotation kullanmak her zaman için avantajlıdır. Code review yapan kişi için bir rehber olarak görev yaptığından, yapılan her değişikliğin sebebinin açıklanmasında önemli rol oynar.
6. Checklist kullanın
   Takımınızdaki her kişinin aynı 10 hatayı tekrar tekrar yapması olasıdır. Bunu önlemek adına oluşturacağınız checklist olası ihmallerin önüne geçer ve sıklıkla yapılan hataları önler.
7. Bulunan hataları gidermek için bir süreç oluşturun
   Code review sırasında geçen süreye göre satır sayısında sınırlama ve anahtar metrikler oluşturma olsa da, hala bir şey eksik. Bu hatalar nasıl giderilecek? Bir çok takımın hala hataları nasıl gidereceği konusunda fikri olmadığı da bir gerçek.
   Hataların en iyi şekilde giderildiğini görebilmenin en iyi yolu bir code review tool kullanmak ve kodu yazan kişiyle iletişime geçmek, aynı zamanda kodda yapılan değişiklik için kendisinden onay almaktır.
8. Pozitif bir code review kültürü oluşturun
   İkili code review takım içerisinde bir gerginliğe sebep olabilir. İkili gruplar arasında yapılan code review’ın hata oranını ölçmek zordur. Bu sebeple, ikili code review’ın başarılı olabilmesi için, yöneticilerin ikili code review’de ekip işi ruhu yansıtan bir şirket kültürü oluşturması önemlidir.
   Bir hatanın negatif olarak görülmesi kolay olmasına rağmen, her hata aslında kod kalitesini arttırma açısından bir fırsattır. İkili code review ayrıca junior developerlara senior developerlardan öğrenim kazanma açısından fırsattır ve ayrıca çok deneyimli developerların bile kötü alışkanlıklarını bırakması açısından bir fırsattır.
9. İkili code reviewın bilinçaltındaki etkisini benimseyin
   Genel olarak diğer insanların yapılan işi incelediğini bilmek, insanların daha iyi iş çıkarmasına sebep olur. Bu “Ego Etkisi” daha temiz kod yazımına sebep olur; çünkü diğer code review kişi muhakkak bu durumun farkına varacaktır. Cisco’nun yaptığı çalışmaya göre ikili code review sonucunda kodun %20-%33’ünde daha az hata yoğunluğu gözlemlenmiştir.
10. Hafif kod incelemesi yapın
    Ekibin zamanını tam olarak optimize etmek adına daha hafif ve yardımlı bir code review önerilir. Cisco’nun yaptığı çalışmaya göre, hafif bir code review, formal review’ın %20’sinden daha az bir zaman alır ve bir o kadar hata bulur. Formal review ortalama 9 saatlik bir sürede 200 satırla sonuçlanır. Genelde verimli olmasına rağmen, bu katı süreç 6 katılımcıya ihtiyaç duyabilir ve saatler süren toplantılara sebep olabilir.