Code review (kod değerlendirmesi) yazılım geliştirmenin en önemli adımlarından birisidir. Kısaca bir geliştiricinin yazdığı kodun başka geliştiriciler tarafından değerlendirildiği ve kodu iyileştirilmesi için yorumlarda bulunduğu bir etkinliktir diyebiliriz.
Kod değerlendirmesindeki esas hedef kod kalitelisini düşüren problemleri yakalamaktır. Buna ilave olarak aşağıdaki ikincil hedefler de bu süreci değerli kılar.
- Daha kaliteli kod yazılması
- Performans ve güvenlik gibi konuların gözden geçirilmesi
- Eğitim verilmesi ve bilgi alışverişi
- Karşılıklı sorumluluk bilincinin artırılması
- Yeni fikirler ile daha iyi çözümler bulma
- QA rehberlerine ve ISO/IEC standartlarına uyum
Düzgün bir kod değerlendirme süreci ile yazılımdaki hatalar erkenden tespit edilebilir ve takımdaki tüm yazılımcıların aynı şekilde kod yazması sağlanabilir. Bununla birlikte doğru bir şekilde icra edilmeyen code review süreçleri, gereksiz zaman kaybına yol açabileceği gibi hem ürüne, hem de yazılımcıya olumsuz etkide bulunabilir. İşte bu tür olumsuzlukları gidermek ve tamamen faydaya odaklanmak için aşağıdaki basit temel hususları takımınızla birlikte uygulayabilirsiniz.
1. Nazik ve saygılı olun
Kod değerlendirmesi yaparken öncelikle karşınızda bir birey ve takım arkadaşı olduğunu unutmayın. Sağlıklı bir takım içi iletişim ortamı kurmak için kod hakkında yorum yaparken nazik ve saygılı olmalısınız. Bunu yapmanın bir yolu, her zaman kod hakkında yorum yaptığınızdan ve geliştirici hakkında asla yorum yapmadığınızdan emin olmaktır. Bununla birlikte yazdığınız koda yorum yapıldığında, bu yorumun sizin karakterinize değil, sadece yazdığınız koda yapıldığını benimseyin.
Kötü yorum: “Concurrency’den elde edilecek bir fayda olmadığı açıkken neden burada multi-thread kullandın?”
İyi yorum: “Buradaki concurrency uygulaması, görebildiğim kadarıyla herhangi bir gerçek performans avantajı sağlamadığı gibi sisteme fazladan karmaşıklık katıyor. Performans avantajı olmadığından, bu kodun multi-thread yerine single-thread olarak çalışacak şekilde yazılmasının doğru olacağını düşünüyorum.”
2. Nedenini yazın
Yorum yazarken sadece yapılması gerekeni değil, nedenini de mutlaka belirtmeye dikkat edin. Böylece kodu yazan kişinin konuyu ve değişiklik talebinizi anlamasını sağlarsınız. Bununla birlikte kişisel gelişimine de katkıda bulunursunuz. Aksi taktirde bir süre sonra kendi fikri olmayan, sadece söyleneni yapan bir takım ile karşı karşıya kalmanız muhtemeldir.
3. Dengeli yönlendirmelerde bulunun
Genel olarak kodu yazan kişi, kod değerlendirmesi sonrası iyileştirmeyi yapmakla sorumludur. Ancak şunu da unutmamak gerekir ki code review, basit bir yorumdan öte yönlendirici ve destekleyici eylemdir. Bazen basit bir yorum yapabilir, bazen konuyu detaylandıran bir açıklamada bulunur ve bazen de doğrudan koddaki değişikliği siz yaparsınız. Burada tam bir denge söz konusudur. Eğer her koda müdahale ederseniz geliştiriciyi gücendirmeye başlarsınız. Geliştiriciyi aşacağını düşündüğünüz veya kodu doğrudan yazarak daha iyi anlatacağınız noktalarda da bundan kaçınırsanız sürecin gereksiz yere uzamasına neden olursunuz. Bunları göz önünde bulundurarak dengeli ve destekleyici bir yönlendirme yapmaya özen gösterin.
4. Demokratik olun
Demokratik bir kod değerlendirmesi sürecinde takımdaki herkesin kodu gözden geçirilir. Yani sadece takım liderinin diğerlerinin kodları hakkında yorum yapması değil, ayrıca takımdaki kişilerin de liderin kodu hakkında yorum yapması durumudur. Diğer bir deyişle tecrübe, pozisyon vb. değişkenleri denklemden çıkartıp ona göre davranmak esastır. Unutmamak gerekir ki tecrübesine bakılmaksızın az ya da çok herkes hata yapabilir. Bir koda ne kadar çok farklı gözle bakılabilirse, o kadar faydalı olacağı açıktır. Önemli olan bu hataları takım olarak birlikte tespit edip, birlikte gidermektir.
5. Cesur olun
Demokratik kod yazma sürecinin bir getirisi olarak başlangıç seviyesindeki (1-3 yıl tecrübeli) bir geliştirici, bir anda kendini kıdemli yazılım geliştiricinin (10+ yıl) kodunu değerlendirirken bulabilir. İşte bu durumda kıdemlilerin ego yapmadan yeni başlayanları cesaretlendirmesi, yeni başlayanların da cesur bir şekilde gördükleri hatalar hakkında yorum yapması gerekir. Aksi taktirde herhangi bir geliştirici gördüğü hatayı bildirmekten çekinirse, işte o zaman hatalar silsilesi başlamış demektir.
Burada değerli Umut Gökbayrak‘ın CTO kod yazmalı mı? isimli makalesinden bir anekdot paylaşmak istiyorum.
…CTO’nun kodunu değiştirmekten çekiniyorlar. Her ne kadar uğraştıysam bu önyargıyı kırmakta istediğim başarıyı gösteremedim. “Ben de hata yapabilirim, hatta sıklıkla yapıyorum” dedim olmadı. “O anda acelem olmuş olabilir, idareten yazmışımdır, alın siz daha iyisini yapın” dedim yine de olmadı. Bu sorun Türkiye gibi aile içi otoritenin halen baskın olduğu kültürlerde karşılaşılan bir sorun. Aile büyüklerine karşı olan saygının bir yansıması olarak, kodumun üzerine değişiklik yapmayı saygısızlık olarak algılıyorlar. Önüne geçilemez mi? Elbette ki geçilir. Ama emek vermeniz lazım.
6. Soru sorun, açıklamalarda bulunun
Soru sormaktan çekinmeyin. Kodda anlamadığınız bir yer olduğunda soru sormanız, o kodun dışarıdan bakan bir kişi tarafından anlaşılmadığı anlamına gelebilir. Cevap verirken genelde kodun baştan yazıldığı bir durum ortaya çıkar. Bu elbette geçerli metoddur ancak bununla birlikte soruya yanıt olabilecek bir comment’i doğrudan kodun olduğu yere ekleyebilirsiniz. Böylece başka bir yazılımcı kodu incelerken aklına aynı soru geldiğinde bu comment’i görebilir. Code review araçlarındaki cevaplar genelde koddan uzak kalır ve kaybolur. Bu nedenle kodun içerisinde verilen cevaplar genel olarak daha kalıcıdır. Tabi bunun da bir dengesi olduğunu göz önünde bulundurmak lazım.
7. Olumlu noktaları belirtin
Kod okurken amaç sadece hata yakalamak olmamalı. Olumlu yanlar da tespit edilmeli ve bu tespitler geliştiriciye bildirilmelidir. Basit bir övgü veya teşekkür düşündüğünüzden çok daha fazla etki bırakabilir. Mutluluk bulaşıcıdır…
“Bu noktayı güzel yakalamışsın.”
“Böyle bir kullanımı olduğunu bilmiyordum. Gayet de kullanışlıymış. Teşekkürler.”
“Ben de bundan sonra bu şekilde implemente edeceğim. Böyle daha anlaşılır olmuş.”
8. Ne kadar sürecekse sürmeli
Code review aceleye getirilecek bir konu değildir. Bütün yorumlar kapanana kadar devam etmelidir. Teslim tarihi yaklaşıyor diye bir hatayı düzeltmemek, iyileştirilmesi gereken bir nokta hakkında tartışmadan süreci geçirmek, sonrasında çok daha ciddi sorunlara neden olur. Ürününüz o atladığınız nokta yüzünden canlı ortamda (production) patlayabilir ve bu sorun size doğrudan müşteri tarafından geri bildirilebilir. Tabi o aşamadan sonra hatayı bildiren hala sizin müşteriniz ise kendinizi şanslı sayabilirsiniz.
Son Sözler
Kod değerlendirmeleri her şirketin ve takımın kendi dinamikleri ile pekişecek süreçlerdir. Yukarıda belirtmiş olduğum genel konular, takımlar özellinde mutlaka değişiklik gösterecektir, göstermelidir. Önemli olan takımın birlikte kazandığı belirli bir kültürü oluşturmak ve bunu yaparken kod kalitesinden ödün vermemektir.
Sizin de tecrübe ettiğiniz konuları okumayı ve yazıyı yorumlarınızla geliştirmeyi çok isterim. Kodunuz kaliteli, hayatınız şen olsun…
Kaynaklar
- https://en.wikipedia.org/wiki/Code_review
- https://google.github.io/eng-practices/review/reviewer/comments.html
- https://medium.com/ctonun-el-defteri/cto-kod-yazmal%C4%B1-m%C4%B1-c6a79b43d70d
- https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/
