Kod incelemesi iyi bir uygulama mıdır?

Çalıştığım şirket yeni yöneticileri işe aldığında, bize her toplantının kodunu gözden geçirmemizi teklif ettiler. İki haftada bir toplantılar yapıyoruz, bu yüzden geliştiricilerden biri projektörde kodunu göstermek içindi ve diğerleri bunu tartışacaktı.

Bunun harika olacağını düşündüm: Her geliştirici kod yazarken daha dikkatli olur ve deneyimlerimizi daha iyi paylaşabiliriz. Ama bir şekilde bunu unuttuk ve teklif az önce bir teklif olarak kaldı.

Bunun faydaları nelerdir ve herhangi bir sakıncaları var mı?

Kod incelemeleri harika bir uygulamadır.

Muhtemelen hatalardan ders almanın ve belirli problemlerin başkaları tarafından nasıl çözüleceğini görmenin en iyi yoludur. Ayrıca, kaliteyi bir kod tabanında tutmanın en iyi yollarından biridir.

Kod incelemeleri birçok şirkette olur, ancak hepsinin takip ettiği belirli bir süreç olduğunu söylemek zordur.

Daha resmi kod incelemesinde, bir kıdemli (veya birkaç yaşlı), kodlarını gözden geçirmek, önerilerde bulunmak ve aynı zamanda öğretmek için bir geliştirici ile birlikte oturur.

Kod incelemelerine ek avantajlar (bu soru için yorumlandığı gibi) şunları içerir:

• Öğretmek ve öğrenmek için harika bir yol
• Bir kod tabanının (stil ve deyimler) tutarlılığını iyileştirmenin ve korumanın en iyi yollarından biridir.
• Tüm ekip üyelerinin projede kullanılan stil ve deyimleri ve bunların nasıl kullanılacağını anlamalarına yardımcı olurlar.
• Kod incelemeleri, böcekleri yakaladıkları ve kusurları erken tasarladıkları için gelişmeyi hızlandıracaklardır (bu nedenle, başlangıçtaki gelişmeyi yavaşlatsalar da, sonraki geliştirme dönemlerinde kar payı öderler)
• Kod inceleme sürecini kolaylaştırmaya yardımcı olan bir takım desteği var

Kod incelemeleri , özellikle yeni ekip üyeleriniz varsa, öğrenme için çok yararlı bir araçtır . Eh, aynı zamanda akran inceleme süreci olarak da bilinir :)

Farklı kod incelemeleri vardır:

• Omuz üzerinden - bir kod geliştiricinin kod yazarken, geliştiricinin kod yazarının omzuna baktığı yerde.
• E-posta geçişi - Kaynak kodu yönetim sistemi, kontrol yapıldıktan sonra otomatik olarak gözden geçirenlere e-posta gönderir. Yorumdan ayıkla: Yönetimi, herhangi bir tür resmi kod incelemesi için zaman ayırmaya ikna etmedim, iş arkadaşlarımın değişikliklerini incelemek için aldığım her şeyi, Tortise'de yerleşik tarih / fark araçlarını kullanarak kaynak kontrolünden aşağı yeni revizyonlar çıkardığımda değiştirdim.
• Çift Programlama - İki yazar aynı iş istasyonunda birlikte kod geliştirir, Ekstrem Programlamada sıkça rastlanır.
• Araç destekli kod incelemesi - Yazarlar ve hakemler, eş kod incelemesi için tasarlanmış özel araçlar kullanır.

associated disadvantageResmi kod incelemelerinin inceleme etkinliği ve uygulama süresi için hazırlık için ciddi bir yatırım gerektirdiği yalnızca bir tane var .

Daha fazla referans aşağıda listelenmiştir (daha derin dalış okumaları için)

• MSDN - Kod İnceleme
• Başvurunuz Gönderilmeden Önce Güvenlik Açıklarını Bulun ve Düzeltin
• Wiki bağlantısı

Bu özel uygulama verimsiz ve utanç verici gibi görünüyor - hatalarının bir bütün insan grubuna işaret etmesini isteyen. Dolayısıyla, incelenecek olanı seçemiyorlarsa ve kod henüz üretimde değilse, bu durum insanları rahatsız edecek duruma gelir.

Kodun ne zaman gözden geçirildiğine bağlı olarak, kod inceleme yorumlarının koda girip girmemesi konusunda büyük fark yaratabilirsiniz. Eğer dev sadece üretim kodunu seçip seçerse, yorumların uygulanması pek mümkün değildir. Geliştiricilerin, başkalarının ilgisini çekeceğini öğrendikleri şık bir teknik gösterebilecekleri toplantılar yapmak güzel, ancak bu kod incelemesi değil. Bu eğitim.

QA'ya taşınmadan önce her kod parçasının kod incelemesini yaparız. Her parça. Genel olarak yalnızca kod gözden geçiricisini ve geliştiriciyi içerir. Kod gözden geçiricisi resmi olarak geçinceye kadar KG'ye gitmez. Bu yüzden geliştirici değişiklikleri yapmak zorunda. QA'nın bulamayacağı birçok sorunu bulduk ve hızlı bir şekilde düzelttik (kod incelemesinde de göremediklerimizi bulurlar). Ayrıca, kovboy kodlamasını azaltır ve iyi performans göstermeyen insanları hızlı bir şekilde tanımlar, böylece sorunlarımızı çözebilir ve uygulamamıza zarar vermeden önce onlardan kurtulabilir veya onlardan kurtulabiliriz. Kod gözden geçirme süresi, çalışmayı planlarken süremizin bir parçası olduğundan, son tarihi hiçbir zaman etkilemez. Ve aslında, uzun vadede zaman kazandırır, çünkü sorun ne kadar erken bulunursa düzeltilmesi o kadar kolay olur.

Şahsen daha az deneyimli geliştiricilere kod incelemesiyle daha iyi teknikler öğrettim ve kodumdaki yorumlarının yanı sıra diğer kişilerin kodlarını da gözden geçirerek kendimi daha iyi teknikler öğrendim. Daha fazla kod incelemesi, başkasının kodu daha bakımlı hale getirme yolunda ilerleyen bir kodu daha iyi anlamasını sağlar. Bazen kod çalışır, ancak incelemenin soruları, kodun anlaşılması zor olduğu için mantıksal sorunların olacağını açıkça ortaya koyar. Akılda tutulması, bu gibi durumlarda, aklınızda hala taze iken, kod yazarı bile başını kaşımaya başladığında ve kodun neden böyle yaptığını merak ettikten daha iyidir.

Bu tür kod incelemesiyle ilgili sorun, iki haftada bir geliştirici, ilerleme yavaş olacak. Herkesin spot ışığında bir dönüş yapması aylar alabilir.

Kod incelemeleri iyi olsa da, bunların arkasında ve bunları yapma prosedürünün arkasında bir sebep olmalı.

Birkaç konuda karar verilmesi gerekirdi:

• Geliştiriciyi kim seçer ve ne kadar bildirim verilir? Hiçbir uyarı incelemesi tuzak değildir.
• Kodun incelenmekte olan kısmını kimler seçer: yönetim, projedeki kıdemli geliştirici veya incelenen geliştirici.
• Kodu projektördeki kişiye nasıl daha iyi bir şey yapılacağını öğretmek veya odadaki diğer herkese kodunu nasıl geliştireceğini öğretmek için projektördeki kodu olan kişinin amacıdır.
• Bu şekilde kodun yüzde kaçı gözden geçirilecek, bu QA sürecinin bir parçası mı olacak?

Bu planı öneren kişiler zaten bu sorulara cevap veremiyorsa, tüm büyük şirketlerin kod incelemelerini nasıl yaptıkları hakkında bir makale okuması mümkündür, bu nedenle arkalarındaki amacı anlamadan bunları da yapmalıyız.

Kod inceleme, yalnızca kod inceleme fikri geliştirme ekibinden geldiğinde harika bir uygulamadır. Geliştiricilerin, birbirlerinin kodlarını incelemek için projektörlere ve sunumlara ihtiyacı yoktur. İsterlerse konferansa gitmeyi tercih ederler.

Kod gözden geçirme fikri yönetimden geldiğinde - düşük yazılım kalitesinin araştırılması gibi gelebilir ve geliştirme ekibini terfi edebilir. Yönetim ekibinin kod inceleme sürecine dahil olması gerektiğini düşünmüyorum. Kod yönetimi ekibi ile yan yana gözden geçirme - çok kötü, öldürme ve yıkıcı uygulama.

Kod gözden geçirmesi, özellikle bilgiyi paylaşmak için geliştiriciler tarafından yapıldıysa ve temel kurallar, öneri ve eleştirilerin YAPICI olması ve hedef uygulama için bireysel bir geliştirici kullanmaması gerektiği için önceden belirlenmiş olması durumunda mükemmel bir uygulamadır.

Geliştiriciler olmayan yöneticiler, kod incelemeleri yapmaya karar verirlerse geliştiriciler tarafından şüphe ile karşılanacaktır. Çoğu yönetici türü, geliştiricilerin doğal olarak koda bakarken girdikleri ayrıntıya girmek istemeyecektir. Çoğu yönetici, geliştiricilerin neden bir yaklaşımı diğerine karşı eleştirdiğini de anlamıyor.

Geliştiricilerin yönetime yaptığı iyi işleri göstermek istiyorsanız, "kod incelemesi" farklı bir anlama gelir ve geliştiriciler arasında kod kalitesini öğretmek / geliştirmek için yapılan kod incelemeleri kadar ayrıntılı olmamalıdır. Bu tür bir sunum, yöneticilerin ne anladığına (değer, yatırım getirisi, vb.) Odaklanarak, sunum daha yüksek ve daha az kod spesifik olabilirse geliştiricilerin ne yaptığını göstermede yardımcı olabilir. Yöneticilerin Joe'nun şirkete önemli miktarda katma değer verdiğini anlatabilir; X'i yaparak, zamandan tasarruf Y miktarını veya sipariş başına Z dolarını, vb. Gösterebiliriz. ekibinizin üyeleri. Bununla birlikte, dikkatli olmanız gerektiğini unutmayın, izleyicilerinizi jargon veya çok fazla ayrıntı düzeyiyle boğmazsınız.

Kod incelemelerinin vurgulamak istediğim öğretim için çok yapıcı olduğu konusunda hemfikir olmama rağmen, yine de benim için ekibin tasarım kalıplarının doğru bir şekilde izlenmesini sağlamak.

Küçük bir prototip çalışması yazıyoruz ve kod parçalarını yeniden değerlendiriyoruz ve sonunda ürünle rahat hissederken okunabilirlik zarar gördü - insanlar ona bakamıyor ve neler olduğunu açıkça göremiyorlar.

Bağımsız gözler her zaman faydalıdır, çünkü siz bazı düşünce tarzlarına sıkışıp kaldığınızdan eminim ve bu her deneyim seviyesinde. Tasarıma ve koda saatlerce yatırım yaptınız ve bu nedenle, kod incelemelerinin çabanızın atılacağı korkusu olduğunda başa çıkmak zor. Yine de, sonunda, umarım, daha temiz, daha yalın ve daha yönetilebilir bir uygulama ile son bulursunuz ve deneyim sizde yerleşiktir.

Ekibimiz için @ElYusubov'un söylediği gibi yapıyoruz ve Kod İnceleme - Pota için özel bir araç kullanıyoruz. İnsanlar kodları inceler, yorumlar ve imzalar. Her hafta oturup ilginç ve / veya karmaşık kod parçalarını yüz yüze inceleriz.

Bir yazılım mühendisliği stajyeri olarak kod incelemelerini çok faydalı buldum.

Ekibimde, her bir taahhüt için bir kod incelemesi gerekiyor (büyük değişiklikler resmi, sonunda küçük değişiklikler 'hızlı görünüm' oluyor). Mühendislik / tasarım bölümlerimin bundan çok etkilendiğini hissediyorum, özellikle beyaz tahtayı hemen hemen terminalden daha fazla çıkardığım için 'izledim' olduğumu bildiğim için. :)

Aslında, sadece biraz dezavantajı biraz daha yavaş bir gelişme süresi olduğu için çok daha iyi bir kod ürettiğini düşünüyorum (ki bence bu, korkunç şekilde tasarlanmış bir kodu düzeltmek / uzatmak zorunda kalmamanız durumunda uzun vadede buna değer). Ayrıca, eğer takımda gençler / stajyer varsa, değerli geri bildirim şansını takdir edeceklerini düşünüyorum. Biliyorum!

Benim tecrübelerime göre, Kod İnceleme, eğer iyi performans sergiliyorsanız gerçekten harika bir şey. Profesyonel / olgun ekip üyeleriniz ve yöneticileriniz olduğunda. Biz programcılar olarak "çözüm çözücüleriz". Bizim işimiz "metin" satırları oluşturmak değil. Bu yüzden fikirleri, hataları, sorunları ve deneyimleri paylaşmalıyız. Kod incelemesi, bunu başarmak için gerçekten iyi bir uygulamadır.

Maalesef kulağa çok hoş geliyor ama çoğu şirkette uygulanması gerçekten zor. Takımınızın çok fazla "özerklik" ihtiyacı var. Yöneticilerinizi veya finans departmanınızı yeni bir özellik yaratmayacağınıza ikna etmek karlı görünmektedir.

Şirketimde bazı kod incelemeleri yapmaya çalışıyoruz. Ancak 'tavşanın peşinde koşmak' için (çok fazla zaman harcanıyor) çok fazla zaman harcanıyor.

Stil ve temel sözdizimi türü kontrollerin çoğu bugünlerde araçlar kullanılarak tutuluyor (FXCop vb.).

Bununla birlikte, kod incelemeleri, özellikle bir ekibin yeni üyeleri, karmaşık veya yüksek etkiye sahip şeyler (örneğin, başarısız olursa veya iş etkisine neden olursa önemli kişilere dikkat çekecek bir şey) ve özellikle kısa vadeli yüklenicileri taşırken veya kullanırken (özellikle tekrar) iyi anadili konuşmacı olmadıklarında çeviri hataları / dil sorunları, yazılımın tüm testleri geçmesine izin verebilir, ancak aslında yapılması gerekeni yapmaz).

Bir ekibin seçmesi için projektöre kod koyma hayranı değilim - başka bir ekip üyesinin (takım lideri vb.) Dev ile bir listeden geçtiği bir kod inceleme toplantısına katılmak daha iyi. Bu, daha az insanı etkiliyor - stil argümanları için çok fazla zaman harcanıyor - ve bu durum için daha az utanç verici. Gerçek sorunları özümsemesi ve “bunu yapardım…” gibi yorumlar tarafından kör edilmemesi daha yapıcı ve kolaydır.

Ayrıca, yürürlüğe konmamış kod incelemelerinin - bir payın üzerine kod koymak ya da birinin öğle yemeğinden vazgeçmesi umuduyla e-postayla göndermek gibi - zaman kaybı olduğunu düşünüyorum.

Kahve yığınında bir liste yığını, bir işaretleyici ve bir fincan kahve ile oturup bunun için mükemmeldir.

Bu tür bir grup gösterisi ve anlatımı, yeni teknolojiler için veya birkaç jr elde etmek için iyi olurdu. devs up, ancak yeni kod tutarlı bir inceleme kadar iyi olduğunu sanmıyorum. Bire bir yapmak zorunda kalmak daha verimlidir.

Kod incelemesi "bütünün" görülmesine yardımcı olur. Ayrı geliştiriciler yalnızca gereksinimlerini / sorunlarını görme eğilimindedir. CR fikirleri ve çözümleri tüm bakış açısıyla keşfeder. CR, esas olarak gereksiz iş israfını ortadan kaldırmaya yardımcı olur. Tüm ürün daha ucuz ve daha kaliteli.