Code Review Nasıl Yapılır?

Önceki yazılarımda Code Review’ın ne olduğuna ve faydalarına değinmiştim. Bu bölümde ise Code Review’ın nasıl yapılması gerektiğine dair önemli gördüğüm bazı noktaları aktarmaya çalışacağım.

● Cod Review farklı açılardan yapılabilir. Öncelikle Code Review’ın amaçlarına uygun olarak yapılması gerekir. Ana amaç hem kodun, hem projenin gelişmesi, hem de ekibin birbirinin gelişimine katkıda bulunarak hata oranını azaltmaya çalışması olmalıdır. Bu açıdan Code Review’larda kişisel çekişmeler, zıtlaşmalar, inatlaşmalar kaçınılması gereken şeylerdir. Öncelikle hataları azaltıp; toplam faydayı arttırmak önceliklendirilmelidir.

● Code review süresince yazdığımız yorumlarda açıklayıcı bilgiler verilmeli, mantıklı öneriler sunulmalı ve düzgün bir üslup kullanılmalıdır. “Burası neden böyle?”, “Burası çalışmaz”, “Burası çok hoş durmuyor”, “Burası projeye aykırı” gibi yorumlar dikkat çekilmek istenen konu hakkında net bir bilgi içermediği gibi, kırıcı olabilir, yanıltıcı olabilir ve amacını aşabilir. Bu nedenle burada sorunlu gördüğümüz noktalar net bir şekilde açıklanmaya çalışılmalı ve varsa öneriler paylaşılmalıdır. Yeri geldi mi örnek kaynaklar, açıklayıcı bilgiler ya da projenin farklı yerlerine örnek referanslar verilebilir.

● Ekibin kaynaşması ve Code Review sürecini eğlenceli ve ilgi çekici hale getirmek için zaman zaman küçük espriler, sürprizler yapılabilir. Fakat burada ekibin birbirini yeterince tanıması, iletişimlerinin açık olması ve yanlış anlaşılmalara mahal vermeyecek şekilde ilerlemek gerekir.

● Kodları inceleme aşaması farklı şekillerde yapılabilir. Kısa geliştirmeler Git, GitHub, GitLab gibi platformlarla göz ile yapılabileceği gibi; daha büyük değişiklikler kod bilgisayara çekilerek de yapılabilir. Burada önemli olan yorumları doğru dosya ve doğru satırlara yazmaktır.

● Kodlar bir seferde gözden geçirilebileceği gibi; bu işlem büyük geliştirmeler parçalar veya fonksiyonlar bazında bölünerek de yapılabilir. Bunu yaparken süreç tamamlandığında eğer kodun içerisinde bir sorun görmüyorsak “approve” ederek onaylamalı, aksi halde ise yorumlarımızı ekleyerek düzeltilmesini sağlamalıyız. Eğer Code Review yaptığımız geliştirme çok uzun ise; ve aralıklarla yorum yazıyorsak; işlemin devam ettiğini belli etmemiz gerekir. Bunu kullandığımız araçların izin verdiği imkanlarla veya yorum yazarak ifade edebiliriz. Bunu yapmadığımızda geliştirici kodun bir kısmındaki yorumları gördüğünde işin bittiğini düşünerek düzeltmelere girişmesi ve bu durumda aynı işlemleri bir kaç kere yapmak zorunda kalması gibi sonuçlar doğuracaktır. Bu açıdan hem geliştirici hem de gözden geçirme yapan açısından aynı işi defalarca yapma durumunu azaltmak adına buna riayet edilmelidir.

● Code Review yapan ekip üyeleri; bazen sorunlu gördükleri bazen de net anlamadıkları ya da bilmedikleri konuyu yorum olarak sorabilirler. Bu da Code Review’ın önemli bir yönünü oluşturur. Özellikle deneyimi daha az olan ekip üyelerinin, daha deneyimli üyelerin işlerini yorumlamada daha çekingen davranmaları çok sık karşılaşılan bir durumdur.. Oysaki sağlıklı bir ekipte en kıdemlisinden en yeni üyeye kadar herkes kendi bildiği kadar ve kendi bilgisi doğrultusunda Code Review yapar. Günün sonunda ekibin toplam deneyimi bir araya gelmiş olacaktır.

Bu bağlamda “Benim yazdığım da dikkate alınır mı?”, “Benimle dalga geçilir mi?”, “O yazdıysa vardır bir bildiği..” gibi düşünceleri bir kenara bırakmak gerekir. Zira, zaman zaman en kıdemli kişinin dikkatinden kaçabilecek bir konu en yeni ekip üyesi tarafından yakalanıp rapor edilebilir.

● Code Review için gerekli ve yeterli aralıklarda zaman ayırmak gerekir. Bu süre Code Review’ın günlerce sarkmasına neden olmamalıdır. Zira işin akabinde düzeltme aşamaları ve tekrar Code Review aşamaları gündeme geleceğinden; süreci çok geciktirmemek adına her gün, günün belirli bir kısmını buraya ayırmak gerekir.. Bu durum projeye kabul edilen diğer işlerden dolayı sürekli konuya dönmeyi de azaltacak olup; geliştiricinin de daha az bölünmesini sağlayacaktır. Böylece geliştiriciler de süreci daha hızlı tamamlayıp; diğer işlere daha çok zaman ayırabileceklerdir.

● Eğer bir projede Unit-testler yazılıyorsa -ki şiddetle önerilir- yazılan kodun testlerinin eklenip eklenmediğine, testlerin yeterli olup olmadığına, eski testlerin yeni kod nedeniyle sorun verip/vermeyeceğine bakılmalıdır.

● Code Review süreçlerinde CI/CD , test koşumu, kalite ölçümleri ve yapılıyorsa ve buralarda belirli kriterler varsa kriterleri sağlamayan işler düzeltilmeden projeye alınmamalıdır.

● Code Review içerisinde iyileştirme önerileri, yeni geliştirme talepleri, ya da Code Review sırasında fark edilen eski kod/süreçlere ait başka problemler görüldüğünde bunlar için ayrı iş talepleri açılmasının sağlanması ve konuların atlanmaması sağlanmalıdır.

● Bir geliştirme yeterli sayıda “approve” alıp merge edildikten sonra dahi olsa;gözden geçirilipsorun görüldüğünde tekrar değerlendirmesi için ilgili geliştiriciye talep açılabilir. Bu yeni bir iş talebi olacağı gibi mevcut bir talebe ekleme şeklinde de olabilir.

Code review ile ilgili yazı dizimiz devam edecektir.