Code Review Nedir?

Code Review, bir geliştiricinin diğer diğer geliştirici tarafından bilinçli ve sistematik olarak bir araya gelerek birbirlerinin kodlarında hata olup olmadığını kontrol etme eylemidir.

Code Review Neden Yapılır?

• Sürekli bir iyileştirme süreci sağlar.
• Performans, kalite standartların belirlenmesi ve uygulanmasını destekler.
• Canlı ortama entegre edilecek geliştirmelerin son kullanıcılarda karşılaşılacak problemlerin önüne geçilmesinde etkisi vardır.
• Ekip içi bilgi paylaşımını destekler. Bireysel ve ekibin teknik anlamda gelişmesine olanak sağlar.
• Bilginin kurum içerisinde yayılmasında önemli bir rol oynar
• 2022 Global DevSecOps Survey katılan geliştiricilerin %76'sı kod incelemelerinin “çok değerli” olduğunu söyledi.

Code Review Hangi Amaçlara Hizmet Eder?

• Geliştirmenin olabilecek en uygun ve iyi hale getirilmesi
• Projeye maksimum katkı ve hakimiyet sağlanması
• Ekibin birbirinin gelişimine katkıda bulunması
• Hata oranını azaltılmaya çalışılması

Code Review Yöntemleri

Code Review yapmanın birçok yöntemi bulunmaktadır. Pair şekilde takımdaki diğer bir geliştirici ile anlık olarak yapılabileceği gibi — pek mümkün olmayan bir senaryo- geliştirme sürecinde standart olarak PR süreci ile geliştirme kapsamında bilgi sahibi ekip arkadaşları assign edilerek ilerletilebilir.

Code Review yaparken ekip arkadaşlarıyla bir araya gelmeden review gerçekleştirmemize yardımcı olan statik kod analizör araçlar da mevcut.

Statik Kod Analizi vs Dinamik kod analizi

Statik kod analizi kodun derleme esnasında yapılan analizdir.

Dinamik kod analizi ise çalışma esnasında yapılan analizdir.

Uygulanacak olan Code Review Aşamaları:

Belirlenen linter — statik kod analizör- kurallarına uygun hatasız şekilde geliştirme tamamlanması

Pull Request sırasında Code Review Checklist de dahil olmak üzere ekip arkadaşlarının geliştirmeyi incelemesi

Geliştirme sonrası CI adımında SonarQube taraması sonrası çıkan hataların düzeltilmesi

SonarQube Nedir?

SonarQube, 29 programlama dilindeki hataları ve kod kokularını -code smells-tespit etmek amacıyla kodun statik analiziyle otomatik incelemeler gerçekleştirmek amacıyla kod kalitesinin sürekli denetimi için SonarSource tarafından geliştirilen açık kaynaklı bir platformdur.

SwiftLint Nedir?

SwiftLint, yazılan kodun kalitesini kontrol eden, hatalar ve uyarılar ile bunları geliştiriciye bildiren üçüncü parti bir kütüphanedir.

Linter kodun doğruluğunu kontrol eden sistemlere verilen genel bir isimdir ve her programlama dilinin kendine özel bir Linter’ı olabilir.(RuffLinter, SonarLint, JSLint)

Bir native iOS projesi için Xcode yazdığınız kodu derlerken bu kodun yazım özelliklerinin doğru olması yeterlidir fakat standartları dikkate almaz.

SwiftLint geliştirici tarafından belirlenen bir dizi kuralı kontrol eder ve bu kurala uymayan kod yazımı tespit ettiğinde Xcode aracılığı ile hata veya uyarı olarak geliştiriciye bildirir.

SwiftLint Ne İşe Yarar?

Uyum

• Swiftlint, kalıpların, girintilerin, aralıkların, stilin ve adlandırmanın tutarlılığını sağlar. Kod bu özelliklere sahip olduğunda, üzerinde çalışmak daha kolay olur ve daha büyük bir güvenle daha hızlı geliştirilebilir.

Okunabilirlik

• Kodun yeni üyeler de dahil olmak üzere ekip üyeleri tarafından kolayca okunup anlaşılabilecek şekilde yazılması ve sunulmasıdır. Bu şekilde kodun okunabilirliği ve anlaşılabilirliği arttırılması yeni bir geliştirme eklemeyi kolaylaştırır.

Kod Kalitesi

• Ekip içerisinde çalışırken bir kod standartları oluşturulmasını sağlar. Kod standartlara uygun olmadığında uyarılar ve hatalar üretilir. SwiftLint analizörleri bir kod tabanının kalitesini değerlendirir ve kodun lint kurallarını ihlal etmesi durumunda uyarılar ve hatalar yapar.

SwiftLint Kurallarına buradan erişebilirsiniz.

Code Review Nasıl Yapılmalıdır?

• Gözden kaçabilecek, belki de projede var olan bir geliştirmenin tekrar gerçeklemesi ya da düşük performansı iyileştirecek noktalar vb. noktaların geliştirme sırasında fark edilemeyebiliyor.
• Bu durumu önlemek amacıyla geliştirme aşaması sonrasında ve testlere başlanılmadan önce gerekli kod incelemesi sonrası iyileştirmeler gerçekleştirilmelidir.

Geliştirme yapma aşamasında olduğu gibi Code Review aşamasında da dikkat dağınıklığı, geliştiricilerin bilgi birikimi, tecrübesi, bakış açısı farklılık gösterebilmektedir.

Code Review ile oluşabilecek hataların minimuma indirgenmesi hedeflenir. Bu sebeple Code Review aşamasında oluşabilecek hataların da minimuma indirgenmesi için Code Review Checklist oluşturularak belirli bir çerçevede Review in gerçekleştirilmesi uygulanan Best Practicelerdendir. Bu çerçeve proje ve kullanına dile göre farklılıklar gösterebilir. Ekip tarafından proje standartlarına göre ilerlenmelidir. Peki kod incelemesi aşamsında nasıl bir iletişim şekli kullanmalıyız?

Dengeli yönlendirmelerde bulunun:

• Genel olarak kodu yazan kişi, kod değerlendirmesi sonrası iyileştirmeyi yapmakla sorumludur. Fakat yapılan code review sonrasındaki yorum, 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

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
• Tecrübe, pozisyon vb. değişkenleri denklemden çıkartıp ona göre davranmak esastır. Bir koda ne kadar çok farklı gözle bakılabilirse, o kadar faydalı olacağı açıktır

Nazik ve saygılı olun:

• Kod değerlendirmesi yaparken öncelikle karşınızda bir birey ve takım arkadaşı olduğunu unutmayın.
• Her zaman kod hakkında yorum yaptığınızdan ve geliştirici hakkında asla yorum yapmadığınızdan emin olmaktır.
• Koda yorum yapıldığında, bu yorumun sizin karakterinize değil, sadece yazdığınız koda yapıldığını benimseyin.

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.

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.”

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.

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ş.”

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

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 testçiniz ise kendinizi şanslı sayabilirsiniz.

Umarım herkes için açıklayıcı ve faydalı olmuştur. Buraya kadar vakit ayırıp okuyan herkese teşekkürler.😊