Bu uygulamadan geldiğimde yeni yerimde kod incelemeleri ile nasıl başa çıkılır?

Yeni şirketimdeki ekibin kod inceleme süreci yok.

Bir zorunluluk kültürü olarak kod incelemesi olan şirketlerden geliyorum ve bu nedenle kodumu bir başkası tarafından incelenmeden yapmakta kendimi rahat hissetmiyorum.

Kod incelemesinin kaliteyi arttırmanın ve zamandan tasarruf etmenin bir yolu olduğuna inanıyorum, çünkü daha önce potansiyel problemleri yakalar (çift programlamadan bahsetmiyorum bile).

• Kod incelemesinin zaman kaybı değil, zaman tasarrufu olduğunu nasıl gösterebilirim?
• Ünite testleriniz varsa kod incelemesi atlanabilir mi?

Ünite testleriniz varsa kod incelemesi atlanabilir mi?

Ama neden?

Akran değerlendirmesinin birincil rolü böcekleri yakalamak değildir.

Evet, bazı olası hataları ve şüpheli, hataya açık kodları tanımlayabilirsiniz, bu genellikle olur, ancak bazen bazı yanlışlıkları tespit etmek, meslektaş incelemesinin hataların varlığını dışlamak için güvenilir bir yol olduğu anlamına gelmez . Bundan uzak. Uygulamanın işlevsel doğruluğunu doğrulamak için doğru bir araç değildir .

Kod incelemesi , kod korumasını zorlar . Bu kodun üretime geçmeden önce temiz ve anlaşılır olmasını (sadece yazarı için değil) talep edeceğim.

Birim testlerinin varlığı buna tamamen diktir. Tamamen anlaşılmaz bir kod için% 100 kod kapsamı ve tüm testlerden geçebilirsiniz.

Kod incelemesi ayrıca, diğer geliştiricilere işinizle ilgili bilgi verir; böylece ne olduğunu ve oradan ne alabileceklerini bilirler veya tatil günlerindeyken hata raporlarını ele alırlar. işlerini iyi yapın - kod tabanını tutarlı tutun (uygulama boyunca benzer desenlere ve kurallara sadık kalın) veya kod yinelemesinden kaçının.

Daha geniş bir şemada, başka bir kişinin kodunu okumayı geliştirici olarak da öğrenir ve büyür.

Birim testleri pek azının yerine geçebilir. Evet, iyi yazılmışlarsa, belgeler gibi okurlar ve bunun için çaba göstermeliyiz. Fakat yine de, bu durum tam tersi, akran incelemesi yapmakla karşılıklı olarak özel değildir - akran incelemesinin tüm avantajları hala geçerlidir, akranlarınızın bakması gereken güzel ünite testlerinin olması, inceleme sürecini daha kolay ve daha faydalı hale getirecektir. gereksiz değil.

Kod incelemesinin zaman kaybı değil, zaman tasarrufu olduğunu gösteren herhangi bir çalışma ve istatistik var mı?

Ben hiçbirini bilmiyorum. Bu tür çalışmaları yürütmek de zor, çünkü biri kod incelemelerini kullanan, diğeri kullanmayan, başarması için eşit ve gerçekçi karmaşıklık görevine sahip iki takıma ihtiyacınız olacak . Muhtemelen aynı problemi çözmelerini istemeniz gerekir , bu da pencereden çok para atmak anlamına gelir. Ve istatistiksel alaka elde etmek için deneyi sık sık tekrarlamanız gerekecek, bu da büyüklük emirleriyle para atmayı artıracak.

Eğer kod incelemeleri kullanan şirketlerin verimliliğini ölçmeyen şirketlere karşı ölçtüyseniz, verimliliği nasıl ölçeceğimiz belli değil, aynı zamanda asıl nedenin ne olduğu da belli değil. Kod incelemeleri daha büyük bir kültürün parçasıdır. Hangi kısmının aslında takımı daha verimli kıldığını söylemek zor (ve takımın ya da projenin yapısına bağlı olabilir). Veya bu kültürün varlığı basitçe şirketin daha küçük veya daha küçük olduğu ve her birinin birçok etkisi olduğu anlamına gelebilir. Ya da sadece kod incelemelerine sunulma istekliliği, egonuza sağlıklı bir mesafeyi engeller veya teşvik eder;)

Ama unutma: ondan almak için kendi tecrüben var. Seni neden işe aldıklarının bir parçası. Bu nedenle, verimliliği arttıracağınıza gerçekten inanıyorsanız (ve ekibiniz aslında bu konuda sıkıntı çekiyorsa), bunu açıkça belirtin.

Ünite testleriniz varsa kod incelemesi atlanabilir mi?

Hayır! Testlerin önemine inanıyorsanız, aslında testleriniz incelenecek ilk şey olmalıdır. Ya saçmalıksa? Veya kapsama berbat ise? Veya davranış yerine uygulama test ederlerse?

Bulduğum bazı rasgele slaytlardan alınmış , ancak zor veriler Steve McConnell'in Code Complete kitabından geliyor:

Kod Değerlendirmeleri Faydalı mı?

"Eş kod incelemelerinin kodunuzu geliştirmek için yapabileceğiniz en büyük şey olduğuna inanıyorum"

Kodlama Korku'dan Jeff Atwood, http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html adresinde

---

"Bireysel denetimler tipik olarak prototip ve yüksek hacimli beta testi hariç diğer tekniklerden daha yüksek olan kusurların yüzde 60'ını yakalar."

Steve McConnell, Kod Tamamlandı 2. Baskı, sayfa 485

Yani% 60 rakamı Shull tarafından IEEE kağıdı gelir ve ark 2002 Biz Kusurların Mücadele Hakkında öğrendiklerini başlıklı bölümü içerir:

"Akran değerlendirmeleri kusurların% 60'ını yakaladı"

Yasal Uyarı: Bu cevap benim kişisel deneyimim :)

Koruduğumuz kod incelemeleriyle çok kötü deneyimler yaptım. Çünkü genellikle sadece bir tane gömlekimiz var ve gözden geçirecek çok fazla şey yok.

Ancak gerçek projelerde iyi deneyimler edindim, sınav saatimde antrenörüm kod düzenlememi gözden geçirdi ve çok sık yaptığım bazı hataları bulmama çok yardımcı oldu, artık yapmam.

Bu yüzden, ne yaptığınıza, kaç kişi olduğunuza vb. Bağlı olduğunu söyleyebilirim.

Ayrıca kod göstermelerinizin bir savaşta sona ermesi riski de önemsiz değildir.

Ekip liderinizden ve / veya meslektaşınızdan, kod incelemeleri normalde yapılmadıysa bile, belki de eğitiminizin bir parçası olarak, kodunuzu tekrar gözden geçirmesini isteyebilirsiniz.

Kodunuzun incelenmeden önce iyi yazılmış ve test edilmiş olduğundan emin olun.

Bir ekip lideriyken, yeni çalışanların kod incelemelerini yapardım (bir süre sonra) kodlarında eleştirmek için herhangi bir hata veya başka bir şey bulmayı bırakırdım ve bu noktada onlarla kod incelemesi yapmayı bırakırdım; Bu ne zaman olurdu:

• Etkileştikleri sistemleri öğrendiler ve benim açıklamalarıma ihtiyaçları yoktu.
• Kodlarını görmeden önce hatasız olana kadar tasarlamayı ve / veya test etmeyi öğrendiler
• Kodlama stil yönergelerim hakkında, kodlarının bakımını yapabileceğimi düşündüğüm şeyler hakkında yeterince bilgi edindiler.

Kod incelemelerinin birkaç amacı vardır:

• Koddaki kusurları bulma
• Ekip üyeleri arasında bilgi transferi

Ekip, deneyimli ekip üyeleri arasında kod incelemelerini atlamayı seçse bile, yeni çalışanların kod incelemelerini yapmanın uygun olduğunu düşünüyorum.

Geliştirilen herhangi bir yazılımda yapılacak kod incelemeleri için küçük kurallar yoktur ... hepsi uygulamanın kapsamına, müşteri boyutuna ve şirket boyutuna bağlıdır. Örneğin, gelecekte başka sürümlerin uygulanmadığı basit bir uygulamanın yapıldığı bir uygulama oluşturuyorsanız, orada birim testi yeterlidir. Ancak, daha hızlı bir performans elde etmek için daha iyi bir şekilde yapılmış olabilecek kodun kısa düşmesi için kodu gözden geçirmeniz gereken uygulamanın performansı hakkında konuşurken tekrar kod incelemesi yapılır.

Kod incelemeleri genellikle 2'den fazla geliştiriciden oluşan bir ekibin olduğu ve teknik liderin uygulamanın kalitesini sağlamak ve uygulamayı gelecekteki geliştirmeler için ölçeklendirmek ve farklı hale getirmek için kod standartlarına uymasını istediği bir teknik liderin olduğu yerlerde yapılır. yaklaşan sürümler.

Örneğin, şimdi birçok CMS açık kaynaklı platformumuz var ve bu platformlar, platform özelliklerini geliştirmek için zaman zaman yükseltmeleri yayınlıyor, bu platformlardan birini kullanan bir geliştirici hayal ediyor ve çekirdek dosyalarda kodlama, uygulama yazma gibi kod standartlarına uymamış. Şablon dosyalarındaki kod ve bu kod üretime geçerse ve daha sonra müşteri platformu yeni sürüme yükseltmek istediğinde, kodlama bu platform için kod standartlarına göre yeniden yapılmazsa asla yükseltilmez. Burada kod incelemesi yapılmadan kodun üretime bırakılması ciddi bir sorun haline geliyor.

Bu yüzden piyasaya sürülmeden önce kod incelemelerinin yapılmasının profesyonel yazılım şirketleri için bir zorunluluk olduğunu ve istisnaların yalnızca geliştiricinin çok deneyimli bir programcı olduğu ve onunla yaşadığı kişisel / çok küçük ölçekli uygulamalar için geçerli olduğunu söyleyebilirim.

Kod incelemeleri, inceleme sürecinin kendisinden gelmeyen avantajlara sahiptir: Yüksek kalitede olan ancak kısa sürede oluşturulan kodları almak için her zaman bir ikilem vardır. Kod incelemeleri olmadan, kendi başınızasınız, bu nedenle kısa sürede kodu yapmak için kaliteden ödün verebilirsiniz. Kod incelemeleriyle düşük kod kalitesinden kurtulmanıza izin vermeyen bu inceleme uzmanı var - bu tam olarak istediğiniz, ilk etapta istediğiniz ve hangi kalitede kod almak için zaman harcamak zorunda kaldığınız? Daha iyi kod yazmak için harcanan her saat hata ayıklamadan (veya daha fazla) iki saat tasarruf sağladığından, zamandan tasarruf edeceğinizi biliyorsunuz.

Kod incelemeleri olmadan, kendi başınızasınız, bu nedenle yüksek kod kalitesini korumak size kalmış. Basit bir çözüm, kendiniz yaptığınız her değişikliği gözden geçirmek ve kalite standartlarınıza uygun olmayan şeyleri düzeltmektir.

Bu aynı zamanda, kod incelemelerinin egoların çatışmasına neden olduğu korkunç durumlardan da kaçınır - programcı A'nın X yöntemini kullandığı durum, B ise Y yöntemini kullanır, böylece A, yöntem X'i yazarsa, yorumlayıcı B Y yönteminde ısrar eder. Böylece A, Y yöntemini kullanarak kodu yeniden yazar; B, kodu yazmış ve A gözden geçirmişse tam tersi olmuş olur.

Kod incelemelerinin savunucusuysanız, korkarım gerçek bir yedek yok. Talihsiz ve basmakalıp dava, (A) uygulamaya aşina olmadıkları ve / veya (B) kod incelemesi için zaman ve çaba harcamayı istemedikleri için kod incelemeleri yapmayan bir çalışma alanıdır. sistem yerinde.

Temel olarak, burada istediğinizi elde etmek için, bir işyeri kültürünün değişmesine ihtiyacınız var - bu asla basit veya kolay değildir. İş yeriniz% 100 olsa bile, kod incelemelerinin mükemmel olduğuna ve bunları benimsemek istediğine ikna olmuş olsa bile, aslında yeni çalışma biçimine geçmenin hala zaman, enerji ve üretkenlik için önemli bir yatırım gerektireceğini unutmayın. Bu yatırım kendini geri öder - ancak yatırıma katkısı olmanız gerekir, sadece kazancı için değil. Roy Osherove'in "Birim Testi ve TDD - Nasıl Gerçekleştirilir" adlı videosuna bakın - kod incelemelerini benimsemenin zorlukları, birim testlerini benimsemeye çok benziyor.

Bu arada, olabildiğince almak için elinizden geleni yapın:

• Kod incelemelerinin değerini gören başka geliştiriciler varsa, gayrı resmi bile olsa, birbirlerini incelemeyi deneyin.
• Eğitiminizden sorumlu bir akıl hocası veya bir geliştiriciniz varsa, ona kod incelemelerinde gördüğünüz değeri açıklayın ve kodunuzu en azından bir kez incelemek isteyip istemediklerini sorun.
• Yöneticinize, başkalarının kodunu gözden geçirmek istediğinizi söyleyin, çünkü sistemi daha iyi anlamanıza yardımcı olacaktır.
• Bir noktada bir takım lideri olursanız, kod incelemelerini yalnızca ekibiniz için yerel olarak ekleyebilirsiniz.

Bunlardan herhangi birinin en büyük yararı, zaman içinde bakımlarını sağlayabiliyorsanız, etrafınızdaki geliştiriciler kod incelemelerini fark etmeye başlayacaktır. Kod incelemelerinin mevcut kültürle nasıl bütünleştirilebileceğini etkin bir şekilde göstereceksiniz - bu da kültürün değişmeye başlamasının yolunu açar. Kod incelemeleri yardımı , küçük bir ölçekte bunun başkalarının - ve bir bütün olarak kültürün - - örneğini izlemenin yolunu açacağını kanıtlayabiliyorsanız.

Endişelenmeyi bırak - yeni iş verenin kod incelemelerini umursamıyor. Yazdığınız kodu kontrol etmenin sorun olmadığını söyleyen başkaları olmadan kendi yeteneklerinize biraz güvenmeyi öğrenin. Yakında, diğer kişilerin kodlarını gözden geçiren, zihinle uyuşan sıkıcı bir süreç olmadan yaşamayı öğreneceksiniz.

Diğer herkesin kullandığı stil kurallarına (veya sadece stiline) uyun. Hangi yorumların yapılması gerektiğine, hangi adlandırma kurallarının kullanılacağına vb. Karar vermek için deneyiminizi kullanın.

Sonra kontrol etmeden önce her şeyi test edin. En önemli şey, doğru şekilde çalışmasıdır.

Eğer yeni işvereniniz kod gözden geçirme fikrinden hoşlanmıyorsa, bunun nedeni eski moda komut ve kontrol tipi metodolojileri ile negatif bir ilişkiye sahip olmaları ve daha modern, çevik tipte bir uygulama seti hedeflemeleri olabilir. Bu durumda, aynı faydaların çoğunu sağlayan ve daha dinamik, modern bir uygulama olarak kabul edilen çift programlama fikrine daha açık olabilirler.