Kodu gözden geçirmede nasıl daha iyi olunur?

Öncelikle kod inceleme sürecine kesinlikle inanıyorum ve her zaman başka birinin kodumu gözden geçirmesini istiyorum. Sorum gerçekten başka birisi için kod inceleme yapmak daha iyi bir iş nasıl yapabilirim etrafında odaklanır?

Bir kod incelemesi gerçekleştirmek için mevcut kodun nasıl çalıştığını ve yerel standardın ne olduğunu bilmeniz gerektiğini biliyorum, her ikisi de çok iyi bildiğimi hissediyorum. Yine de asla diğer insanlar için yeterince iyi bir kod inceleme yapmak gibi hissediyorum. Ayrıca bazı insanlar diğerlerinden daha iyi bir iş inceleme kodu yapmak gibi görünüyor biliyorum bu yüzden büyük kod gözden geçirenler olanlar için kullandığınız teknikler nelerdir merak ediyorum?

Daha iyi kod incelemesi yapmanın bir yolu yoktur. Yapabileceğiniz tek şey öğrenme ve deneyim ile gelişmeyi sürdürür.

Normalde takip ettiğim şeyler

- Use variables judiciously
- Keep things in scope loose boundaries will generate more errors
- Orient your language of coding in domain specific terms, they make more sense
- Keep loops to minimum 2 for each method if needed
- use ternary operators
- Arrange methods alphabetically
- Keep errors at handling ease
- write less but efficient code

Sanırım buna ekleyebileceğiniz çok şey var.

Kendinize başkalarını sizin için iyi bir yorumcu yapan şeyin ne olduğunu sorun.

ayrıca, kod boyunca ilerlerken;

• şimdi anlamadığın bir şeyde dur, bir yoruma ihtiyaç olduğunu yaz
• kodlama standartlarına uygun olup olmadığını belirleyin: boşluklar, parantezler, camelCase..etc
• tüm işlevleri içerdiğinden emin olun
• sınır koşullarını geçip geçmediğini görmek için basit bir mantık testi yapın.

Sadece hedefliyorum

• açıklayan neden önerilen bir değişiklik gereklidir. Nedeni sadece düzeltmeyi değil,
• kod biçimlendirme konusunda anlaşmaya varmak, böylece herkesin kodu aynı / tanıdık görünüyor
• korumak istediğiniz kod özelliklerinin bir listesini paylaşma. Bir wiki'ye koyun, böylece herkes her hatayı bir kez yapmak zorunda kalmaz. Sık sık güncelleyin.

Bunun dışında, "neyi arayacağınızı bilmek" sadece deneyim, pratik ve okuma ile gelir.

Deneyimlerime göre en iyi yol, delik ekibinin kod incelemesini yapmasına izin vermektir. Her projede, sürüm kontrol sistemindeki her kod değişikliğini takip edebileceğiniz bir taahhütlü posta listesi kullanıyoruz. Geliştiricimizin çoğu, kod değişiklikleriyle ilgilendikleri için projeye özel posta listelerine abone oldular.

Birisi yeni kaynak kodunda kötü bir yol fark ettiğinde, yalpalayan bir stajyer ise ya da daha deneyimli bir talihçi ise bu konuda bir tartışma başlatır.

Elbette bu yöntem, özellikle ekip üyelerinden hiçbirinin her bir kod değişikliğini takip etmek için boş zamanları olmadığı durumlarda, tüm yeni kodların gözden geçirilmesini garanti etmez. Ayrıca her geliştirici, her geliştiricinin işini iyi yapmasını sağlamaktan sorumlu değildir, yalnız bunun gözden geçirildiğini garanti edemezsiniz. Ancak, en azından ekiplerimizde her zaman teknik kaliteden sorumlu bir teknik müdür vardır.

Aşağıdaki puanlara uyuyorlarsa, kod incelemelerinin gerçek bir hayranıyım:

• her geliştirici tüm kod ve argümanları kendi görüşüne göre inceleme olanağına sahiptir.
• hiç kimsenin başkalarının kodunu kötüye kullanma hakkı yoktur
• sadece kötü kod bir tartışmayı etkinleştirmekle kalmaz, aynı zamanda iyi bir kod da
• tartışmalar, dahil olan her insan için mutluluklarla sona erer
• inceleme, en azından özellik tamamlanmadan önce neredeyse gerçek zamanlı olarak gerçekleşir

Ne öğrendim ki, her kod satırını gözden geçiren ve kod kalitesi gibi şeyleri kod biçimlendirme veya kod verimliliği açısından kontrol etmeniz gerektiğini düşünüyorsanız, o zaman makinelerin yapabileceği şeyleri yaptığınız için çok verimsizsiniz. sen. Hedefiniz, her bir kod katkısının derleme ve kod kalitesini kontrol eden sürekli bir entegrasyon sistemi kullanmak olmalıdır. Bu sistem raporlar üretir ve katılımcılara gönderirse, her şey mükemmeldir.

İtiraf etmeliyim ki kodu gözden geçirmeniz gerekiyorsa, çünkü bir programcının kalitesini kontrol etmek veya kalitesini sıralamak zorundaysanız, o zaman önerilerim mantıklı değil. Bu durumda kaynak kodunu satır satır gözden geçirmeyeceğim. Şöyle şeyleri gözden geçiririm:

• güvenlikle ilgili sorunlar var mı
• amaçlanan API'lardır
• kod belirtilen mimariyi uyguladı mı
• yararlı testler yazdı mı (ancak yalnızca örtük talimatı verildiğinde öğrenmem gerekiyordu)
• belgeleme
• birikmesi işlem
• ... ve biraz daha fazlası, muhtemelen

Deneyimli bir geliştiriciyseniz, her zaman daha iyi performansla yapabileceğiniz döngüler gibi şeyler bulacaksınız. Tabii ki başkalarına bu tür bilgileri açıklamakta fayda var, ancak bu inceleme oturumunun bir parçası olmamalıdır. Önemli performans sorunları varsa, o zaman liste türünün daha az verimli bir varyantını kullandığından değil.

İlk soru, neden bazı insanların gerçek inceleme başlamadan önce belki bir önizleme yaptıklarına cevap vereceğim diğer insanlar gibi daha iyi bir inceleme yapıyor gibi göründüğü için, muhtemelen kendilerinin hazırlandıkları anlamına gelir, böylece tam olarak ne incelemek istediklerini bilirler. .

[H] ow başkası için kod inceleme yapmak daha iyi bir iş yapabilir miyim?

Onlara bir sürü soru sor

Bir kod incelemesi gerçekleştirmek için mevcut kodun nasıl çalıştığı hakkında bilgi sahibi olmanız gerektiğini biliyorum ...

Aslında, hayır, iyi bir yorumcu olmak için önceden kodu bilmek zorunda değilsiniz.

Birkaç iş önce, işverenim tüm kod check-in'lerinin bir gözden geçiren tarafından imzalanmasını talep etmeye başladı. Çoğunlukla GUI iş c yapıyordum ve benim için en iyi yorumculardan biri benim dostum Bill oldu. C konusunda yeterlidir, ancak çok fazla GUI çalışması yapmamıştı ve incelemelere girerek kodumun nasıl çalışması gerektiği hakkında hiçbir fikri yoktu.

Ama bu konuda birçok soru sordu ve açıklamam gerekiyor ki kodumun ne yaptığını ve benim açımdan neden çok fazla düşünmeyi teşvik ettiğini anlayabildi. Beni uç vakaları olan çok sayıda tuhaf küçük böcek bulmaya ve aynı zamanda benim almış olabileceğim diğer yaklaşımları da düşünmeye yönlendirdi. Ayrıca, bu noktada 22 yıldır C yazıyor ve oldukça yetkin olduğumu düşünmeme rağmen, kod kalitemi hızla geliştirdi.

Artık orada çalışmama rağmen, check-in öncesinde farkları gözden geçiriyorum ve kendime, "Bill'in bu konuda ne gibi soruları olurdu?" Diye soruyorum. Ve sık sık, sonuç olarak bir şeyi değiştirmeye başlarım.