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