Kod İncelemesinin amacı nedir?


76

Kuruluşumu kod incelemelerinin değeri konusunda satmaya çalışıyorum. Çalıştığı çeşitli yerlerde çalıştım. Onları şekillendirme seçimlerini ve fonksiyonel kararları nitelemek için kullandıklarını gördüm ve bunların tehlikeli hiçbir şeyin uygulanmamasını sağlamak için bir bağırsak kontrolünden başka bir şey olarak kullanılmadıklarını gördüm. İçimdeki his, en etkili amacın iki seçenek arasında bir yerde olmasıdır.

Peki bir Kod İncelemenin amacı nedir?


16
İlgili (Yığın Taşması Üzerine): Kod İncelemelerinin Amacı
yannis

16
- Okunabilir ve kolayca bakımı yapılabilir bir kod yazıp yazmadığınızı nasıl bilebilirdiniz? - Arkadaşınız kodu inceledikten sonra size bildirir. Gerekçe: Bunu kendiniz belirleyemezsiniz çünkü kodun kendisinin söylediğinden daha çok yazar olarak biliyorsunuzdur. Bir bilgisayar size, bir resmin sanat olup olmadığını söyleyememesinin aynı sebepleriyle söyleyemez. Bu nedenle, yazdıklarınıza bakmak ve onun fikrini vermek için başka bir insana - yazılımı koruyabilene - ihtiyacınız var. Söz konusu sürecin resmi adı "Akran Değerlendirmesi" dir .
gnat

3
"Kod incelemesinin amacı nedir?" geliştiricilerin terribad kodu yazmasını engellemek ve doğru yönde yönlendirmek için.
zzzzBov

7
Kod İncelemenin bu soruya dolaylı bir cevabı var gibi görünüyor .. sadece sorulara ve cevaplara göz atın, bir kod incelemesinin amacı oldukça belirgin hale gelir :)
Mathieu Guindon

3
Programcıların kaç kez kodlarını bir inceleme sırasında kodlarını açıklamak için basitçe kendi kodlarında keşfettiğini merak ediyorum?
balta etkin değil

Yanıtlar:


75

Kod incelemesi yapmak istemenizin birçok nedeni vardır:

  • Diğer geliştiricilerin eğitimi. Yazılımın geri kalanını anlayabilmeleri için herkesin bir kusur düzeltme veya geliştirme ile ilişkili değişikliği gördüğünden emin olun. Bu, özellikle insanlar entegre edilmesi gereken bileşenler üzerinde veya bir kişinin belirli modüllere bakmadan uzun süre boyunca gidebileceği karmaşık sistemlerde çalışırken faydalıdır.
  • Gelişme için kusurları veya fırsatları bulma. Hem teslim edilebilir kod hem de test kodu ve veriler zayıflıkları bulmak için incelenebilir. Bu, test kodunun sağlam ve geçerli olmasını ve tasarım ve uygulamanın uygulama genelinde tutarlı olmasını sağlar. Ek değişiklikler yapılması gerekiyorsa, giriş noktasına daha yakın bir fırsat yakalar.

Gözden geçirmenin yapılması için birkaç iş vakası vardır:

  • Enjeksiyonlarına daha yakın bir şekilde tekrar işlenmesi gereken hataları veya sorunları bulmak. Bu daha ucuz.
  • Sistem ve karşılıklı eğitimin paylaşılması. Bir geliştiricinin değişiklik yapma hızını arttırması için daha az zaman.
  • Sistemdeki olası iyileştirmelerin belirlenmesi.
  • Test cihazlarının yeterli kapsama alanı sağladığından emin olmak için uygulamayı başlatmak. Siyah bir kutuyu test perspektifinden gri bir kutuya veya beyaz bir kutuya dönüştürme.

Akran değerlendirmeleri için faydaları ve uygulama stratejileri hakkında kapsamlı bir tartışma arıyorsanız , Yazılımdaki Akran Değerlendirmelerini: Karl Wiegers'ın Pratik Rehberini incelemenizi tavsiye ederim .


7
+1, bence ana noktaları doğru noktalara göre iyi tespit ettiniz. Sürekli olarak çok yaratıcı "WTF" çözümleri bulan iş arkadaşlarınızla çalışırken tasarımı tutarlı tutmak ancak düzenli kod incelemeleriyle elde edilebilir.
Doktor Brown,

Temel olarak geliştiricilerin belirtilen standartlara uymasını sağlamak, modülleri tasarlarken düzenleri kullanmak, sağlanan bileşenleri kullanmak ve zaten sorunlara çözüm bulmak için ninja kodları (kasıtlı olarak veya değil) yapmaya başlamak için JavaScript incelemelerinde kod incelemeleri yapıyoruz. için. Ayrıca birisini yanlışlıkla üzerine yazma thisbağlamında, harika .hasOwnPropertyolması gereken yerlerde kullanmadıklarında vb. C # gibi yönetilen bir dilde, ders dışı dersin dinamik diller için daha az nedenleri vardır.
Hayır,

1
Şimdiye kadar cevabınız sadece kod doğruluğundaki iyileştirmelerden bahsetmektedir. Gelişmekte olan cihaz tarafından nadiren doğru bir şekilde ölçülebilecek olan, kodun okunabilirliğini / korunabilirliğini ele almayı başaramaz.
ArTs

51

Kod Değerlendirmeleri bilgi aktarımı için bir araçtır .

  • Geliştiriciler birbirlerinin kodlarını incelediklerinde, sistemin tüm alanlarında aşinalık kazanırlar. Bu, projenin veri yolu faktörünü azaltır ve geliştiricilerin yazmadıkları sistemin bir kısmını bakım yapmak zorunda kaldıklarında daha verimli hale getirir.

  • Bir küçük programcı, bir kıdemli öğrencinin kodunu incelediğinde, küçük programcı, aksi takdirde yalnızca deneyim yoluyla öğrenilen püf noktaları alabilir. Bu ayrıca aşırı karmaşık kodlara karşı düzeltici olarak da çalışabilir.

    Kapsamlı bir kod incelemesi, çeşitli belgelere karşı sık sık kontrol yapılmasını gerektirir. Bir dil veya API öğrenmek için harika bir yol.

  • Üst düzey bir programcı bir gencin kodunu gözden geçirdiğinde, bu sorunları teknik borçlara dönüştürmeden önce sorunları çözmek için bir fırsattır . Bir kod incelemesi, genç programcılara danışmanlık yapmak için iyi bir ortam olabilir.

Kod incelemeleri hakkında değil:

  • … Böcek bulmak. Testler bunun için var. Yine de, sık sık bir kod incelemesinin bazı problemler bulması halinde ortaya çıkacaktır.

  • … Stil konularını nitelendirmek - bir stil için yerleşmek ve bunu uygulamak için otomatik formatlayıcılar kullanmak. Ancak otomatik bir aracın kontrol edemediği birçok şey var. Kod incelemeleri, kodun yeterince belgelendiğinden veya kendiliğinden belgelendiğinden emin olmak için iyi bir yerdir.


2
nitpicking tarzı meselelerindeki son noktanız, tamamen aynı fikirdeyim - küçük bir geliştiricinin kodunu incelerken can sıkıcı bir deneyim yaşadık ve en göze çarpan şikayeti aslında tarzıydı, ancak kolayca programlı bir şekilde olan stil problemleri değil zorla .... waaaaaay edgecas vb için ifadeler çok fazla ise; evet, bazı durumlarda bir bilgisayarı bulabileceğiniz sorunlardan biri, ancak çoğu senaryo tarafından genel olarak bulunmaya değmeyecek konular değildi. Bunu görmeye başlamamız için 30 saniyelik bir okuma, bir başkasına 30 tane daha açıklamamız ve umarım konuyu düzeltmemiz gerekir. Buna hala şokta: /
pasifist

7
@pacifist Cevaplayıcının tanımladığı tarz bu değil. Stil, parantezlerin yerleri, çentiklenme vb. İle ilgilidir. Eğer küçük geliştiriciniz çok fazla kullanıyorsa, ifadelerinizde stilden tamamen farklı bir probleminiz varsa; STYLE kodlamanın genel bir özelliği, performansı etkilememesidir. Ve önemli miktarda if ifadesinin performansı etkileyeceğini düşünüyorum.
Pimgd

12
Bir inceleme yaparken, genellikle "bu bir hataya benziyor" diye düşündüğüm şeyleri saptadım, sonra bunun bir hata olduğunu kanıtlamak için belirli bir test senaryosu yazarım. Yani kod incelemelerinin birçok hedefinden biri hata bulmak. Bu yüzden “kod inceleme veya testler” bakış açısının biraz fazla kenarlı olduğunu düşünüyorum.
Doktor Brown

2
@DocBrown'a ek olarak, kolayca test edilemeyen durumlar vardır - veri yarışları, bazı kilitlenme türleri, geçitler, tanımsız davranışlar / değerler (çoğunlukla C / C ++'da ancak tanımlanmamış olarak karma tablolardaki öğelerin sırası) veya kaynak pırasa (dosyayı bir döngüde açmak GC'de bile kötü bir fikir olabilir). Bunlardan bazıları yeterince akıllı-derleyici-statik analiz ile tespit edilebilir .
Maciej Piechotka

2
@pacifist, sizin özel örneğiniz bir kod incelemesinde tamamen patlatılır. Aynı zamanda herhangi bir statik kod analizörü için kırmızı bayrak olacaktır (Döngüsel karmaşıklık 17!). Bir kod incelemesi bu işlevi hızlı bir şekilde anlamsal stilde (veya hatta algoritma!) Bir problem olarak tanımlar. Ancak. Bu tür bir sorun sadece bir "stil" sorunu değildir. Eğer böyle davranırsanız, yakında deponuzda gerçekten çok kötü bir kod olacak; sonuçta sadece "stil".
Pimgd

12

Şahsen kod incelemesinden elde ettiğim en değerli şey, kodun başka bir kişi tarafından anlaşılacağı konusunda güvende olmasıdır . Değişkenler açıkça adlandırılmış mı? Her kod grubunun amacı oldukça açık mı? Bir yorumda belirsiz bir şey var mı? Son durumlarda ve parametrelerde geçerli değerler yorumlarda ana hatlarıyla belirtilmiş ve kod içinde kontrol edilmiş mi?


2
Bu, önceki 4
cevaptan daha

2
@gnat: Diğer cevaplar bilgi aktarımını ve tespit hatalarını ele alıyor. Bunlar önemlidir, ancak bir kod incelemesinden daha fazlası var.

1
Söyleyebildiğim kadarıyla, bu cevabın bir kısmı daha makul olarak ele alınmaktadır : "Eş değerlendirmelerinin faydaları ve uygulama stratejileri hakkında kapsamlı bir tartışma arıyorsanız, Yazılımdaki Eş İncelemeleri incelemenizi tavsiye ederim: "Karl Wiegers'den Pratik Bir Rehber." Bu cevap ayrıca şunları kapsar: "aşırı karmaşık kodlara karşı bir düzeltici"
gnat

2
@gnat Diğer cevaplarda ortaya çıkan noktaların farklı bir yönünü vurgular. Altı ay önce yazdığınız kendi kodunuzla hiç şaşırdınız mı? Kod incelemesi bu işlemi hızlandırmanıza olanak sağlar. Eğer meslektaşınız kodunuzdan dolayı şaşırıyorsa, sorun hala hafızanızda hala taze iken bunu netleştirebilirsiniz.
200_success

1
@ 200_success belki de. Ancak bu nokta, eğer gerçekten oradaysa, gerçekten kötü bir şekilde sunulmuş görünüyor. Yorumunuz bile bu "cevaptan" daha iyi iletişim kurmayı başarıyor. Bunu sadece ilgili bir soruda açıklayan kanonik cevabı ifade eden önceki bir yorumda gösterilenleri tekrar ettiğini söylemekten bahsetmiyoruz
gnat

7

Diğer harika cevaplar tarafından kapsanmayan iki alan eklemek istiyorum:

Kod incelemelerinin büyük sebeplerinden biri , bizim durumumuzda aşağıdakilere çevrilen Hawthorne etkisidir : Eğer birisinin daha sonra kodunuza bakacağını biliyorsanız, o zaman daha iyi yazmanız daha olasıdır.

Bir başka büyük neden daha iyi güvenli geliştirme uygulamaları için. Bir kişinin güvenli bir geliştirme yaşam döngüsünde uygun kod incelemelerinin önemini anlamak için yalnızca Apple’ın goto başarısızlığına (yanlışlıkla kopyalanmış bir kod satırı) veya Heartbleed böcekine (giriş doğrulamasında temel bir başarısızlık ) bakması gerekir .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.