Kod kalitesini artırmak için birçok yol vardır; unit test, continuous integration, continuous deployment, agile methodology. Bu noktada en önemli yollardan biri de code review yöntemidir.
Kaliteli diyebileceğimiz kodlar yazmaya çalışsanız bile acil yetiştirmemiz gereken bir proje olduğunda spaghetti code yazma durumunuz olabiliyor. Bu gibi durumlarda geriye dönüp yazmış olduğunuz kodu, review-refactoring etmemiz gerekmekte.
Code review; kod kalitesini artırmak, önünüze çıkacak bugları, güvenlik açıklarını tespit etmek ve buna uygun çözümleri sunmak için kullanılan yöntemdir.
????Code review nedir?
Geliştirilmekte olan projelerde, kod kalitesini iyileştirmek, geliştiricilerin kod becerilerini ve kullanmış oldukları teknolojiye olan becerilerini geliştirebilmelerini sağlamak, bug’ları minimize etmek ve alternatif çözüm yolları üzerine fikir pratiği yapmak amacıyla fikir alışverişinin sağlanmasıdır.
Temel amacı, kod kalitesini arttırmak olan bu etkinliğin asıl sebebi, bir ekip içinde herkesin aynı düzeyde olmaması problemini çözmektir.
Code review için seçilen kişi/kişiler kodun asıl sahibi ile kurdukları diyaloglarda problemi açıklayıcı bir şekilde iletişim kurması çok daha faydalı olacaktır.
????En İyi Code Review Uygulamaları
Kod incelemesi için en iyi 9 uygulama şunlardır:
1. Bir kod incelemesinde neleri arayacağınızı bilin.
2. Derleme ve test aşamalarına dikkat etmelisiniz.
3. Kodu 60 Dakikadan uzun süreli incelemeyin.
4. Bir seferde 400’den fazla satır kontrol etmeyin.
5. Yardımcı olacak geri bildirim verin.
6. Hedefleri ve beklentileri iletin.
7. Kod inceleme sürecine herkesi dahil edin.
8. Olumlu bir kültürü teşvik edin.
9. Zamandan kazanmak için bazı işleri otomatikleştirin.
????Neden Code Review(Kod Gözden geçirme) yapmalıyız/yapmamalıyız?
Temel amacımız kod kalitesini arttırmak. Code Review(Kod Gözden geçirme) yaptığımızda projenin her alanında yetkinliğimiz artar.
Code review, test aşamasından önce yapılırsa bugların önüne geçilmiş olunur.
Ekipteki kişilerin yetkinlik düzeyleri birbirlerinden farklıdır. Deneyimli kişiler tecrübelerini daha az deneyimli kişilere bu şekilde aktarma imkanı bulurlar.
Code Review yapan kişinin söylediği her şey doğru olmayabilir, bu noktada etkileşimli olarak en doğru sonucu bulmak gerekiyor.
Code Review(Kod Gözden geçirme) yaparken hiç bir kurala uymuyorsak Code Review(Kod Gözden geçirme) bizim için sadece bir zaman kaybı olacaktır.
????Code Review Standartı
Kod incelemesinin temel amacı, genel kod sağlığının zaman içinde iyileştiğinden emin olmaktır. Kod incelemesinin tüm araçları ve süreçleri bu amaçla tasarlanmıştır.
İlk olarak, geliştiriciler görevlerinde ilerleme kaydetmeleri gereklidir.
Kod tabanına asla bir iyileştirme sunmazsanız, kod tabanı asla iyileşmez.
Diğer taraftan, gözden geçirenin görevi, her CL’nin, kod tabanlarının genel kod sağlığının zaman geçtikçe azalmayacağı bir kalitede olduğundan emin olmaktır. Gözden geçiren kişi, incelediği kod üzerinde sorumluluğa sahiptir. Kod tabanının tutarlı, sürdürülebilir olması gereklidir.
Tüm code review yönergeleri arasında çok önemli ilkelerdir.
Buradaki temel nokta, “mükemmel” kod diye bir şeyin olmamasıdır. Mükemmeli aramak yerine, gözden geçirenin dikkat etmesi gereken en önemli şey, sürekli iyileştirmedir. Sistemin sürdürülebilirliği, okunabilirliği ve anlaşılabilirliği sağlanmalıdır.
Mentorluk: Bilgiyi paylaşmak, bir sistemin kod sağlığını zaman içinde iyileştirmenin önemli bir parçasıdır. Bir geliştiricinin yeni şeyler öğrenmesine yardımcı olacak yorumlar bırakmak her zaman gereklidir.
Prensipler: Teknik gerçekler ve veriler, kişisel tercihlerinizi geçersiz kılar. Yazılım tasarımı, neredeyse hiçbir zaman kişisel bir tercih değildir.
Gözden geçiren kişi, yazardan sistemin genel kod sağlığını kötüleştirmediği sürece mevcut kod tabanındakilerle tutarlı olmasını isteyebilir.
Anlaşmazlıkları Çözme: Bir kod incelemesiyle ilgili herhangi bir sorun yaşanması durumunda, ilk adım her zaman geliştiricinin ve gözden geçiren kişinin CL Yazar Kılavuzu’na ve bu Gözden Geçirenler Kılavuzu’na dayanarak fikir birliği oluşturmaya çalışması olmalıdır.
code_checklist
????Code review sürecinde nelere dikkat edilmeli?
Öncelikle Code Review Standardını inceleyerek başlayabilirsiniz.
Tasarım: Bir incelemede ele alınacak en önemli şey, CL’nin tasarımıdır. CL’deki çeşitli kod parçalarının etkileşimleri mantıklı mı? Bu değişiklik kod tabanınıza mı ait? Sisteminizin geri kalanıyla bütünleşiyor mu? Bu işlevi eklemek için iyi bir zaman mı?
İşlevsellik: CL, geliştiricinin amaçladığını yapıyor mu? Geliştiricinin amaçladığı şey bu kodun kullanıcıları için iyi mi?
Gözden geçiren kişiler uç durumlar hakkında detaylı düşünmeli, eşzamanlılık sorunları aramalı, bir kullanıcı gibi düşünmeye çalışmalıdır.
Bazı değişiklikler için, CL’de ekleme yapmak ve denemek çok zahmetli ise, geliştiricinin size işlevselliğin bir demosunu vermesini sağlayabilirsiniz.
Bir kod incelemesi sırasında işlevsellik hakkında düşünmenin önemli olduğu başka bir nokta ise, paralel programlamanın olup olmadığıdır. Bu tür sorunları sadece kodu çalıştırarak tespit etmek çok zordur ve genellikle birisinin sorunları ortaya çıkarmadığından emin olmak için dikkatlice düşünmek gerekir.
Karmaşıklık: CL olması gerekenden daha karmaşık mı? CL’nin her seviyesinde bu durumu kontrol edin.
Fonksiyonlar çok mu karmaşık? Sınıflar çok mu karmaşık?
Testler: Değişikliğe uygun olarak birim, entegrasyon veya uçtan uca testleri yapılmalıdır.
CL’deki testlerin doğru, mantıklı ve yararlı olduğundan emin olun.
Testlerin aynı zamanda korunması gereken kodlar olduğunu unutmayın. Ana ikilinin parçası olmadıkları için testlerde karmaşıklığı kabul etmeyin.
Adlandırma: Geliştirici proje için net adlandırma yaptı mı?
İyi bir isim, okunması zorlaşacak kadar uzun olmaksızın, öğenin ne olduğunu veya ne yaptığını tam olarak anlatacak kadar uzun olmalıdır.
Yorumlar: Geliştirici anlaşılır net yorumlar yazdı mı? Tüm yorumlar gerçekten gerekli mi?
Kodların neden var olduğunu açıkladıklarında yorumlar oldukça faydalıdır. Kod kendini açıklayacak kadar net değilse, o zaman kod daha basit hale getirilmelidir.
Yorumların, bir kod parçasının amacını, nasıl kullanılması gerektiğini ve kullanıldığında nasıl davrandığını ifade etmesi gereken sınıfların, modüllerin veya işlevlerin dokümantasyonundan farklı olduğunu unutmayın .
Tarz: Google’da tüm ana dillerimiz ve hatta küçük dillerin çoğu için stil kılavuzlarımız vardır. CL’nin uygun stil kılavuzlarına uyduğundan emin olun.
Stil kılavuzunda olmayan bir stil noktasını iyileştirmek istiyorsanız, geliştiricinin kodu iyileştireceğini düşündüğünüz ancak zorunlu olmadığını düşündüğünüz bir nitpick olduğunu bildirmek için yorumunuzun önüne “Nit:” ekleyin. CL’lerin yalnızca kişisel stil tercihlerine göre gönderilmesini engellemeyin.
Tutarlılık: Mevcut kod stil kılavuzuyla tutarsızsa?
Bazı durumlarda stil kılavuzu gereksinimleri bildirmek yerine önerilerde bulunur.
Başka bir kural geçerli değilse, yazar mevcut kodla tutarlılığı korumalıdır.
Her iki durumda da, yazarı bir hatayı dosyalamaya ve mevcut kodu temizlemek için bir TODO eklemeye teşvik edin.
Dokümantasyon: Bir CL, kullanıcıların kodu oluşturma, test etme, etkileşim kurma veya yayınlama şeklini değiştirirse, README’ler, g3doc sayfaları ve oluşturulan tüm referans belgeleri dahil olmak üzere ilişkili belgeleri de güncellediğini kontrol edin.
Kodu okumak sizin için çok zorsa ve bu, incelemeyi yavaşlatıyorsa, geliştiriciye bunu bilmesine izin vermeli ve siz incelemeden önce açıklamasını beklemelisiniz.
Bağlam: CL’ye geniş bir bağlamda bakmak ve CL’yi bir bütün olarak sistem bağlamında düşünmek de yararlıdır.
????Dikkat Edilmesi Gerekenler
Tek seferde maximum 400 satır kodu gözden geçirin.
Cisco’nun yaptığı bir çalışmaya 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.
Yapılan bu işlemin 60 ile 90 dk arasında tamamlanmasının daha sağlıklı olacağı da iddia ediliyor.
Saatte 300-500 satır kodu gözden geçirmeye çalışın
Gözden geçirme oturum süresi 1 saatlik farklı bloklar şeklinde olmalı. Uzadığı takdirde gözden geçirilen kod üzerindeki konsantrasyon kaybolacaktır. Code review yapan kişi daha çok satır kodla ilgilendiği zaman, daha az satır koda verdiği önemi aynı verimlilikle gösteremiyor.
“Code Review” ve “Pair Programming” ayrımı yapılmalı
Kodu yazan kişinin müdahale etmesi durumu, “Pair Programming”e dönüşecektir. Kodu gözden geçirilecek kişiden öncesinde bir hazırlık yapması kodu gözden geçirecek kişiye yardımcı olacaktır.
Kodu yazan kişi değil, kod gözden geçirilmeli
İkili code review, ekipler içerisinde gerginliğe neden olabilir. Bu sebeple, ikili code review’ın başarılı olabilmesi için, yöneticilerin ikili code review’de ekip ruhu yansıtan bir kültür oluşturması gerekir.
Eğer kodu gözden geçiren kişi, kodu yazan kişiye göre çok daha tecrübeli bir kişiyse bu deneyim kazanma açısından bir fırsattır.
Checklist kullanın
Code review sırasında takip edilebilecek bir liste olması, sık yapılan hataların tekrarını önler.
Hedef belirleyin ve mümkünse bir uygulama kullanın
Kod gözden geçirme, hem kodu gözden geçiren, hem de kodu gözden geçirilen için oldukça önemli bir adım. Bu noktada code review’i sistematik hale getirmek ve unutmamak için code review eklentisi veya uygulama kullanabilirsiniz.
Bir süreci başlatmadan önce, takım olarak verimliliğini nasıl ölçeceğinize karar vermelisiniz. Aşağıdaki metrikleri izlemek iyi bir çözüm olacaktır:
Inspection rate: Code review hızı
Defect rate: Bir saatlik review’da bulunan hata sayısı
Defect density: Kod satır sayısına göre hata oranı
