Geçen yılki bazı ciddi kalite sorunlarının ardından şirketim son zamanlarda kod incelemeleri yaptı. Kod inceleme süreci, kurallar veya herhangi bir kontrol listesi olmadan hızlı bir şekilde uygulamaya kondu.

Başka bir geliştirici ve ben, sistemde yapılan tüm değişiklikleri, bagajda birleştirilmeden önce incelemeyi seçtik.

Ayrıca "Teknik Kurşun" olarak seçildik. Bu, kod kalitesinden sorumlu olduğumuz anlamına gelir, ancak süreçte değişiklik yapma, geliştiricileri yeniden atama veya projeleri geri tutma yetkisine sahip değiliz.

Teknik olarak birleşmeyi inkar ederek gelişime geri verebiliriz. Gerçekte bu, patronumuzun zamanında sevk edilmesini talep etmesiyle neredeyse her zaman sona erer.

Yöneticimiz, yaklaşmakta olan projelerin programlarını oluşturmakla ilgilenen bir MBA programıdır. Deneme aşamasındayken, yazılımımızın iş açısından ne yaptığı hakkında hiçbir fikri yok ve bir geliştiriciden açıklama yapmadan en temel müşteri taleplerini bile anlamakta zorlanıyor.

Halen gelişim SVN'deki geliştirme branşlarında yapılıyor, geliştirici hazır olduğunu düşündükten sonra, bilet sistemimizdeki bileti müdürümüze atar. Yönetici daha sonra bize atar.

Kod incelemeleri ekibimizdeki bazı gerilimlere neden oldu. Özellikle eski üyelerden bazıları değişiklikleri sorguluyor (yani "Biz her zaman böyle yaptık" veya "Neden yöntemin mantıklı bir adı olmalı, ne yaptığını biliyorum?").

İlk birkaç haftadan sonra meslektaşım iş arkadaşlarıyla sorun çıkarmamak için işlerin kaymasına izin vermeye başladı (bana kendisi, bir hata raporundan sonra bir müşteri tarafından dosyalandığını, böceği bildiğini söyledi; geliştirici işaret ettiği için ona kızardı).

Öte yandan, şimdi, taahhüt edilen kodla ilgili sorunları belirtmek için bir eşek olduğum bilinmektedir.

Standartlarımın çok yüksek olduğunu sanmıyorum.

Şu andaki kontrol listem:

• Kod derlenecek.
• Kodun çalışacağı en az bir yol var.
• Kod çoğu normal durumla çalışacaktır.
• Kod, birçok uç durumda çalışacaktır.
• Girilen veriler geçerli değilse, kod makul bir istisna atar.

Ancak geri bildirim verme biçimimin sorumluluğunu tamamen kabul ediyorum. Zaten bir şeylerin neden değiştirilmesi gerektiğini açıklayan, bazen de bir şeyin neden belirli bir şekilde uygulandığını bile sormak için eyleme geçilebilecek noktalar veriyorum. Kötü olduğunu düşündüğüm zaman, onu başka bir şekilde geliştireceğimi belirtiyorum.

Eksik olduğum şey, "iyi" olarak işaret edecek bir şey bulma yeteneğidir. Birinin kötü haberi iyi haberlerde yemeyi denemesi gerektiğini okudum.

Ama iyi bir şey bulmakta zorlanıyorum. “Hey, bu sefer gerçekten yaptığınız her şeyi yaptınız”, hoş ya da yardımcı olmaktan daha küçümseyici.

Örnek Kod İncelemesi

Selam Joe,

Library \ ACME \ ExtractOrderMail Class'taki değişiklikleriniz hakkında bazı sorularım var.

Neden "TempFilesToDelete" u statik olarak işaretlediğini anlamadım. Şu anda "GetMails" için ikinci bir çağrı bir istisna atar, çünkü dosyalara dosya eklersiniz, ancak silindikten sonra bunları asla kaldırmazsınız. Fonksiyonun sadece çalışma başına bir kez çağrıldığını biliyorum, fakat gelecekte bu değişebilir. Bunu sadece bir örnek değişken yapabilir misiniz, o zaman paralel olarak birden fazla nesneye sahip olabiliriz.

... (İşe yaramayan diğer bazı noktalar)

Küçük puanlar:

• Neden "GetErrorMailBody", Kural Dışı Bir İstisna alıyor? Bir şey mi kaçırdım? İstisna atmıyorsunuz, sadece iletin ve "ToString" deyin. Neden?
• SaveAndSend Yöntem için iyi bir isim değil. Bu yöntem, bir postanın işlenmesi yanlış giderse hata postaları gönderir. Bunu "SendErrorMail" olarak veya başka bir şeyle yeniden adlandırır mısınız?
• Lütfen eski kodu yorum yapmayın, tamamen silin. Hala yıkılma içinde.

Kod incelemesinde olumlu şeyler nasıl bulunur?

Geçen yılki bazı ciddi kalite sorunlarının ardından şirketim son zamanlarda kod incelemeleri yaptı.

Harika, firmanız için değer yaratma konusunda gerçek bir fırsatınız var.

İlk birkaç haftadan sonra meslektaşım iş arkadaşlarıyla sorun çıkarmamak için işlerin kaymasına izin vermeye başladı (bana kendisi, bir hata raporunun bir müşteri tarafından dosyalanmasından sonra, hatayı bildiğinden ama geliştiriciden korktuğunu söyledi. işaret ettiği için ona kızardı).

İş arkadaşınız, geliştiricilere kodlarında neyin yanlış olduğunu söyleyemiyorsa kod incelemesi yapmamalıdır. Sorunları bulmak ve müşterileri etkilemeden önce onları düzeltmek sizin işiniz .

Aynı şekilde, iş arkadaşlarını korkutan bir geliştirici kovulmak istiyor. Bir kod incelemesinden sonra kendimi korkuttum - patronuma söyledim ve kullanıldı. Ayrıca işimi seviyorum, bu yüzden olumlu ve olumsuz geri bildirimlere uydum. Bir eleştirmen olarak, bu benim üzerimde, başkası değil.

Öte yandan, şimdi, taahhüt edilen kodla ilgili sorunları belirtmek için bir eşek olduğum bilinmektedir.

Bu çok talihsiz, inceliğini söylüyorsun. Bakacak daha fazla şeyin varsa, övmek için daha fazlasını bulabilirsin.

Kodu eleştirin, yazarı değil

Bir örnek verelim:

Değişiklikleriniz hakkında bazı sorularım var

"Siz" ve "sizin" kelimelerini kullanmaktan kaçının, "yerine" deyin.

Bir şey mi kaçırdım? [...] Neden?

Eleştirilerinize retorik güzelleşmeler eklemeyin. Şaka da yapma. Duyduğum bir kural var, "Söylemeniz iyi hissettiriyorsa, söyleme, iyi değil."

Belki de kendi egonuzu başkalarının pahasına çalıyorsunuzdur. Sadece gerçeklere sakla.

Olumlu geri bildirim vererek çubuğu yükseltin

Geliştiricilerinizi daha yüksek standartlara ulaştığında övmek için çıtayı yükseltir. Yani bu soru anlamına gelir,

Kod incelemesinde olumlu şeyler nasıl bulunur?

iyi bir tanesi ve ele almaya değer.

Kodun nerede daha yüksek seviyedeki kodlama uygulamalarının ideallerini karşıladığını belirtebilirsiniz.

En iyi uygulamaları takip etmelerini ve çıtayı yükseltmeye devam etmelerini sağlayın. Herkesin daha kolay idealleri bekledikten sonra, bunlardan övgüyü kesmek ve övgü için daha iyi kodlama uygulamaları aramak isteyeceksiniz.

Dile özgü en iyi uygulamalar

Dil koddaki belgeleri, ad alanlarını, nesne yönelimli veya işlevsel programlama özelliklerini destekliyorsa, bunları çağırabilir ve uygun olan yerlerde kullanmaları için yazarı tebrik edebilirsiniz. Bu konular genellikle stil rehberlerine girer:

• Kurum içi dil tarzı rehberlik standartlarını karşılıyor mu?
• Dil için en yetkili stil rehberine uyuyor mu (muhtemelen kurum içi olandan daha katıdır - ve bu nedenle hala kurum içi stille uyumludur)?

Genel en iyi yöntemler

Çeşitli paradigmalar altında, genel kodlama prensipleri hakkında övgüye değer noktalar bulabilirsiniz. Mesela, onların en güzelleri var mı? Unittests kodun çoğunu kapsıyor mu?

Aramak:

• yalnızca konu işlevselliğini test eden ünite testleri - test edilmesi amaçlanmayan pahalı işlevsellik ile alay.
• API'lerin eksiksiz bir şekilde test edilmesi ve semantik olarak halka açık fonksiyonellik ile yüksek seviyede kod kapsamı.
• birim testleri için alay edilmiş işlevsellik dahil olmak üzere uçtan uca işlevselliği test eden kabul testleri ve duman testleri.
• iyi adlandırma, kanonik veri noktaları yani kod KURU (Kendinizi Tekrar Etmeyin), sihirli dizeler veya sayılar yok.
• Değişken adlandırma o kadar iyi yapılır ki, yorumlar büyük ölçüde gereksizdir.
• temizleme işlemleri, objektif gelişmeler (takaslar olmadan) ve kodu orijinal yazarlara tamamen yabancı yapmaksızın kod satırlarını ve teknik borçları azaltan uygun yeniden yapılandırmalar.

İşlevsel Programlama

Dil işlevselse veya işlevsel paradigmayı destekliyorsa, aşağıdaki idealleri arayın:

• küresellerden ve küresel durumdan kaçınmak
• kapanışları ve kısmi fonksiyonları kullanma
• okunabilir, doğru ve açıklayıcı isimleri olan küçük işlevler
• tek çıkış noktaları, argüman sayısını en aza indirir

Nesneye Dayalı Programlama (OOP)

Dil OOP'yi destekliyorsa, bu özelliklerin uygun kullanımına övgü alabilirsiniz:

• kapsülleme - temiz bir şekilde tanımlanmış ve küçük bir ortak arayüz sağlar ve ayrıntıları gizler.
• devralma - kod, muhtemelen karışımlar aracılığıyla uygun bir şekilde yeniden kullanıldı.
• polimorfizm - arayüzler, belki de soyut temel sınıflar, parametrik polimorfizmi desteklemek için yazılmış fonksiyonlar tanımlanır.

OOP altında, SOLID ilkeleri de vardır (belki de OOP özelliklerinin bir kısmı fazlalık olabilir):

• tek sorumluluk - her nesnenin bir paydaşı / sahibi vardır
• açık / kapalı - kurulu nesnelerin arayüzünü değiştirmemek
• Liskov ikame - alt sınıflar ebeveyn örnekleri için ikame edilebilir
• arayüz ayrımı - kompozisyon tarafından sağlanan arayüzler, belki karışımları
• bağımlılık inversiyonu - tanımlanan arayüzler - polimorfizm ...

Unix programlama prensipleri :

Unix ilkeleri modülerlik, açıklık, kompozisyon, ayırma, basitlik, eşitlik, şeffaflık, sağlamlık, temsil, en az sürpriz, sessizlik, onarım, ekonomi, üretim, optimizasyon, çeşitlilik ve genişletilebilirliktir.

Genel olarak, bu ilkeler birçok paradigma altında uygulanabilir.

Kriterleriniz

Bunlar çok önemsiz - Bunun için övgüde bulunursa, küçümsenmiş hissederdim:

• Kod derlenecek.
• Kodun çalışacağı en az bir yol var.
• Kod çoğu normal durumla çalışacaktır.

Öte yandan, bunlar, neyle uğraştığınızı düşündüğünüz düşünülerek oldukça yüksek övgülerdir ve geliştiricilerin bunu yaptıkları için övgüde bulunmaktan çekinmeyeceğim:

• Kod, birçok uç durumda çalışacaktır.
• Girilen veriler geçerli değilse, kod makul bir istisna atar.

Kod incelemesini geçmek için kural yazıyor mu?

Bu teoride harika bir fikir, ancak, genellikle kötü adlandırma kodunu reddetmezken, o kadar kötü adlandırma gördüm ki kodu düzeltmek için yönergelerle reddedeceğim. Herhangi bir nedenle kodu reddetmeniz gerekiyor.

Kodu reddetmek için düşünebildiğim tek kural, üretimden uzak tutacağım kadar korkunç bir şey olmaması. Gerçekten kötü bir isim, üretimden uzak tutmaya istekli olacağım bir şey - ama bunu bir kural haline getiremezsiniz.

Sonuç

Dil destekliyorsa, birden fazla paradigma altında ve muhtemelen hepsinde takip edilen en iyi uygulamaları övün.

Kesin ve özlü bir örnek olmadıkça ve doğrudan odaklanmış konu ile ilgili olmadıkça iyi bir şey seçmekle uğraşmayın.

Şekerlemeyeceğim - seslerinden, yetenekleriyle güvensiz olan ve işleriyle ilgili zorlukla karşı karşıya kalmaya çalışan en az bir kişiyle uğraşıyorsunuz. Ayrıca işlerinde muhtemelen kötüdürler - iyi bir geliştirici her zaman kendini yansıtmaya, yapıcı eleştirilere kapılmaya ve yollarını değiştirmeye açık olmalıdır.

Şimdi havada olan şey senin hakkında konuşalım. Makul olduğunuzu düşünüyorsanız, topun yuvarlanabilmesi için bu gibi insanlara daha fazla dikkat etmeniz gerekir. Bu insanlarla başa çıkmanın en iyi yolunu, şeyleri nasıl söylediğinize çok dikkat etmektir.

Yazarı değil, kodu suçladığınızdan emin olun . Kod tabanınız olan korsan-dağdan ziyade eldeki tek meseleye odaklanın, bunlar yaratmada önemli bir ele sahip olabilirler ve daha kişisel bir saldırı olarak görülebilirler. Öncelikle savaşlarınızı seçin, kendilerini kullanıcılarınıza gösteren kritik konulara odaklanın; böylece, söylediğiniz her şeyi işten çıkarmanıza yol açan kişide bir eleştiriler dizisi çıkarmayacaksınız.

Beden dili ve sesi, eğer onlarla şahsen konuşuyorsanız, söylediklerinizden açıkça anlayın ve onlarla konuşmadığınızdan veya teknik becerilerini alamadığınızdan emin olun. Büyük olasılıkla yarasanın hemen savunmasında olacaklar, bu yüzden endişelerini gidermek yerine çözmeniz gerekiyor. Bilinçli olarak onların yanında olduğunu düşünmeleri için açık bir şekilde konuşmadan bu konuşmanın bilincinde olmanız gerekir ve umarım dikkatlerini çeken değişiklikleri yapmaları gerektiğini kabul ederler.

Bu işe yaramazsa, biraz daha agresifleşmeye başlayabilirsiniz. Ürün bir konferans odasından çalıştırılabilirse, kod incelemesi sırasında projektöre getirin ve hatayı ilk elden gösterin, eğer bir yönetici tam oradaysa, kişinin geri tepmemesi daha iyidir. Bu onları utandırmak değildir, ancak sorunun kullanıcı için gerçektir olduğunu ve sadece kodlarıyla ilgili bir yakınmanız yerine, düzeltilmesi gerektiğini kabul etmeye zorlamaktır.

Sonunda, hiçbir yere varamazsanız, bir anaokulu öğrencisi gibi birine davranmaktan bıktınız ve yönetim sorundan tamamen habersiz ve ya bir kod yorumcusu olarak performansınıza zayıf bir şekilde yansıyor ya da kodunuzu iyi değerlendirmeyi umursuyorsunuz. şirket ve / veya ürün, patronunuzla davranışları hakkında konuşmaya başlamanız gerekir. Mümkün olduğu kadar açık ve kişisel olun - üretkenlik ve kalitenin acı çektiği bir iş durumu yaratın.

Kod incelemeleri toksik olabilir, zaman kaybetmek, yaşayan inek savaşlarına neden olur. Sadece temiz kod-yorum, yorum adlandırma kuralları, ünite ve entegrasyon testi, kontrol etme stratejileri, RESTfulness vb.

Bundan kaçınmanın tek yolu, kod incelemesini geçmek için kuralları yazmaktır.

O zaman check-in yaptıran veya onaylayan bir kişi değil. Sadece kurallara uyulduğunu kontrol ediyorlar.

Ve önceden yazılmış olduklarından, kodunuzu yazdığınızda kuralları takip edebilir ve gerekçenizi açıklamak zorunda kalmazsınız veya daha sonra tartışmak zorunda kalmazsınız.

Kurallardan hoşlanmıyorsanız, değiştirmek için bir toplantı yapın.

Sizin görüşlerinize şeker katlanmam, çünkü patronlaştırıcı olarak kabul edilebilir.

Benim düşünceme göre, en iyi uygulama daima koda odaklanmak ve asla yazara odaklanmamaktır.

Bu bir kod incelemesi, geliştirici incelemesi değil , bu yüzden:

• "Döngü asla bitmeyebilir", "Döngü asla bitmeyebilir"
• "Senaryo X için bir test durumu gerekli" değil, "Bu senaryoyu kapsayacak şekilde testi yazmadınız" değil

İnceleme hakkında başkalarıyla konuşurken aynı kuralı uygulamak da çok önemlidir:

• "Anne, bu kod hakkında ne düşünüyorsun?", "Anne, Jon'un kodu hakkında ne düşünüyorsun?"

Kod incelemesi performans incelemesi zamanı değildir - ayrı olarak yapılmalıdır.

Ben şimdiye kadar herhangi bir cevapta belirtildiği edilmemiştir ve belki de şaşırdım benim kod değerlendirmeleri ile deneyim sıradışı biridir ama:

Neden birleştirme isteğinin tamamını tek bir iletide inceliyorsunuz?

Kod incelemeleriyle ilgili deneyimim GitLab; Her zaman diğer kod inceleme araçlarının benzer şekilde çalışacağını hayal ettim.

Bir kod incelemesi yaparken , farkın özel, bireysel satırları hakkında yorum yaparım . Bu son derece de kod-ve aslında bir üzerinde açıklama olduğu için, kişisel eleştiri olarak alınacak olası görüntülenen yorumları gibi kod üzerinde, kodunun altına doğrudan gösterilen bu bir yorumdur.

Ayrıca tüm birleştirme isteği hakkında yorum yapabilir ve sık sık bunu yapabilirim. Ancak, farkın özel çizgileri üzerinde belirli noktalar belirtilebilir. (Ayrıca, farkın değişeceği şekilde yeni bir taahhüt eklendiğinde, "modası geçmiş fark" hakkındaki yorumlar varsayılan olarak gizlenir.)

Bu iş akışı ile kod incelemeleri çok daha modüler ve daha az uyumlu hale gelir. Bir kod incelemesinden bir satır basitçe şöyle diyebilir:

Güzel bir yaklaşım, bunu özel bir işleve sarmak!

Ya da söyleyebilir

Bu nesne adı gerçekten nesnenin amacına uymuyor; belki yerine 'XYZ' gibi bir isim kullanabiliriz?

Veya bir bölümle ilgili büyük sorunlar varsa, şunu yazabilirim:

Bu kodun çalıştığını görüyorum (ve neden işe yaradığını görüyorum ) ancak anlamak için odaklanmış bir çalışma gerektiriyor. Gelecekte daha kolay bakımını yapması için ayrı ayrı işlevlere yeniden yerleştirebilir misiniz?

(Örnek: ABC işlevi aslında burada üç şey yapıyor: fooyu temel almak, bozun önünü kesmek ve zorf'u kızartmak. Bunların hepsi ayrı işlevler olabilir.)

Yukarıdakilerin tümünü yazdıktan sonra, birleştirme isteğinin tamamı hakkında özet bir yorum yapabilirim:

Bu harika bir özellik ve birleştirildikten sonra gerçekten faydalı olacak. İşlev ismini temizleyip, yaptığım yorumlarda belirtilen yeniden düzenleme işlemlerini yapabilir misiniz ve daha sonra tekrar bakmamı söyler misiniz? :)

Birleştirme isteği tam bir köpeğin kahvaltısı olsa bile , bireysel yorumların her biri basit olabilir. Sadece daha fazlası olacak. Sonra özet yorum şunu söyleyebilir:

Özür dilerim, ama bu kod gerçekten işe yaramaz. Yanlış ele alınacak ve kötü bir kullanıcı deneyimi, hatta bir durumda veri bozulmalarına yol açacak birçok bireysel durum (bireysel yorumlarda belirtildiği gibi) vardır. (Bkz. 438a95fb734 numaralı taahhüt üzerine yapılan yorum.) Bazı normal kullanım durumları bile çok kötü uygulama performansına neden olacaktır (bazı dosyalar için fark hakkındaki bireysel açıklamalarda belirtilen özellikler).

Üretime hazır olmak için bu özelliğin, akıştaki her noktada hangi varsayımların güvenli olduğu konusunda verilen daha fazla dikkat ile yeniden yazılması gerekecektir. (İpucu: Denetlenmediyse hiçbir varsayım güvenli değildir.)

Tam bir yeniden yazma beklemeden birleştirme isteğini kapatıyorum.

Özet: Gözden teknik kod bireysel hatlarda yorumlar gibi kod yönlerini. Sonra bu yorumları birleştirme isteğine ilişkin genel bir yorumda özetleyin . Kişisel olma - sadece gerçeklerle ve kod hakkında değil kodunuzla ilgili görüşünüz . Ve fikrinizi gerçeklere, doğru gözlem ve anlayışa dayandırın.

Kimsenin almadığına gerçekten şaşırdım, ancak yayınlanan örnek incelemede yanlış bir şeyler var.

Doğrudan Joe'ya hitap etmen için hiçbir sebep yok. Joe'nun başarısızlıklarını düzelttiği seni ilgilendirmez. Bu birisi senin işin. Endişen, kod kalitesi. Dolayısıyla, istek / sipariş / talep yazmak yerine (eğer Joe olsaydım, bunun için meşru olmadığın için basitçe reddedebilirdim), rolüne devam et ve basit bir isimsiz yapılacaklar listesi yaz.

İyi ve kötü puanlar vermek konusunda adil olmaya çalışmak sadece imkansız değil, tamamen sizin rolünüzden de değildir.

İncelemenizden alınan içeriğe sahip yeniden biçimlendirme örneği:

• Library \ ACME \ ExtractOrderMail Class'ta değişiklik yapmadan önce, birkaç sorunu çözmemiz gerekiyor.
• Bir şeyi kaçırmadığım sürece "TempFilesToDelete" statik olmamalıdır.
• Gelecekte, çalışma başına bir kereden fazla işlev diyebiliriz, bu yüzden ihtiyacımız var (burada yapılması gerekenler).
• "GetErrorMailBody" nin bir İstisna parametresini neden aldığını anlamam gerekiyor. (ve ben burada sınırdayım, çünkü şimdiye dek bir sonuca sahip olmalısınız )
• SaveAndSend, örneğin "SendErrorMail" gibi davranışına daha iyi uyması için yeniden adlandırılmalıdır.
• Yorumlanan kod okunabilirlik amacıyla silinmelidir. Olası geri dönüşler için subversion kullanıyoruz.

İncelemeyi bu şekilde formüle ederseniz, okuyucunun bizden ne kadar nefret ettiği önemli değildir, burada tek görebildiği, birinin daha sonra devam etmesi gereken gelişmeler hakkında notlar. Kim? Ne zaman ? Kimse umursamaz. Ne ? Neden ? Söylemelisin.

Şimdi, kod incelemelerinin insan faktörünü denklemin dışına alarak gerginliğin artmasının nedenini ele alacaksınız.

Kod incelemesinin asıl amacı problem bulmaktır. Herhangi bir hata varsa, yapabileceğiniz en iyi şey başarısız olan bir test senaryosunu yazmaktır.

Takımınız (menajeriniz) böcek üretmenin oyunun bir parçası olduğunu söylemelidir, ancak onları bulmak ve düzeltmek herkesin işini kurtaracaktır .

Düzenli toplantılar yapmak (takım veya çift) ve birkaç sorunu çözmeniz yararlı olabilir. Orijinal programcı kasıtlı olarak problemleri ortaya koymadı ve bazen bunun yeterince iyi olduğunu düşünebilir (ve bazen de olabilir). Ancak bu ikinci göz çiftine sahip olmak tamamen yeni bir görünüm sunar ve sorunlara bakmaktan çok şey öğrenebilir.

Gerçekten kültürel bir şey ve çok fazla güven ve iletişime ihtiyacı var. Ve sonuçlarla çalışma zamanı.

Bence yapılacak olumlu şey, incelemelerden önce kodlama standartları konusunda bazı fikir birliği sağlamak olacağını düşünüyorum. Diğerleri, girişi olduğunda bir şeyleri daha fazla satın alma eğilimindedir.

Adlandırma kuralları gibi bir şey için, bunun önemli olup olmadığını başkalarına sorun. Çoğu geliştirici özellikle akranları arasında hemfikir olacaktır. Programlama dünyasında bu kadar yaygın olan bir şeyle aynı fikirde olmak istemeyen kişi olmak ister? Birinin kodunu seçerek ve kusurları işaret ederek işleme başladığınızda, çok savunmacı olurlar. Standartlar belirlendiğinde, yorumlamada ya da "yeterince iyi" sayılan şeyde bir anlaşmazlık olacaktır, ancak şimdi sizden daha iyisin.

Bu sürecin diğer bir kısmı kod incelemelerinin itirazları nasıl ele alacağını belirlemektir. Bu sonsuz bir tartışma haline gelemez. Bir noktada, birinin karar vermesi gerekiyor. Belki yargıç olmak için üçüncü bir taraf olabilir ya da hakem bütün gücü alır. Yapılması gereken şeyler olmalı hedef.

Bunun son parçası, herkesin Code Reviews’ın sizin fikriniz olmadığını bilmesi, kalacakları ve herkesin en iyisini yapmak için çaba göstermesi gerektiğidir. Herkes kendini güçsüz hissediyorsa, belki de kodunuzu gözden geçirmesine izin verilebilir mi?

Umarım, yönetim için ölçülebilir bir sonuç, hataları, müşteri şikayetlerini, gecikmeleri vb. Sınırlamaktır. Aksi takdirde, birisi "kod incelemesi" kelimesini yeni duymuş ve işleminize eklerlerse, mucizeler çok fazla zaman harcamaz, enerji ortaya çıkarır. ve buna harcanan çaba.

Bu zor olabilir, ancak ölçülecek iyi bir şey yoksa, iyi geri bildirim verme konusunda endişelenmeyin.

Ancak, gelecekte, geliştiricilerin kodlarını geliştirmeye başladıkları zaman, onlara iyi geribildirim vermek isteyeceksiniz. Koddaki gelişmeleri belirtmek isteyeceksiniz ve ayrıca bir bütün olarak ekibe faydalarını da belirtmek isteyeceksiniz. İyileşme görmeye başladığınızda, onlar da olacaktır ve işler yavaş yavaş ortaya çıkmaya başlamalıdır.

Başka bir şey; Bir savunma havası olabilir çünkü bir sözleri yokmuş gibi hissediyorlar. Neden birbirlerinin kodlarını incelemelerine izin vermiyorsunuz? Onlara özel sorular sorun ve onları dahil etmeye çalışın. Onlara karşı sen olmamalısın; bir takım çalışması olmalı.

1. Vaktiniz olsaydı bu kodda neleri değiştirirdiniz?
2. Kod tabanının bu alanını nasıl geliştirirsiniz?

Şimdi sor ve altı ay sonra sor. Burada bir öğrenme deneyimi var.

Asıl mesele - garanti edilmediği durumlarda kod için övgü verme, fakat çabayı tanı ve kesinlikle gelişimi tanı. Gözden geçirmeyi bir rakip yerine bir takım alıştırması yapmaya çalışın.

Gerilimsiz Kalite

Kod hakkında söylenecek olumlu şeyleri nasıl bulabileceğinizi sordunuz, ancak asıl sorunuz, “ciddi kalite problemlerini” ele alırken “ekibinizdeki gerilimleri” nasıl önleyebileceğinizdir.

Sandviçin "iyi haberdeki kötü haberi" eski numara geri tepebilir. Geliştiricilerin ne olduğunu görmeleri muhtemel: bir eşantiyon.

Kuruluşlarınız Yukarıdan Aşağıya Sorunlar

Patronlarınız size kaliteyi sağlama konusunda görev verdi. Kod kalitesi için bir kriter listesi aldınız. Şimdi, ekibinize olumlu pekiştirme fikirleri istiyorsunuz.

Neden takımını mutlu etmek için ne yapman gerekiyor? Takımına sormayı düşündün mü?

Kibar olmak için elinden geleni yapıyorsun gibi geliyor. Sorun, mesajınızı nasıl ilettiğiniz değildir. Sorun, iletişimin tek yönlü olması.

Bir Kalite Kültürü Oluşturmak

Aşağıdan yukarıya doğru büyümek için bir kalite kültürünün yetiştirilmesi gerekir.

Patronunuzun kalitenizin yeterince hızlı bir şekilde gelişmeyeceğinden ve Harvard Business Review'dan bir tavsiye almayı denemek istediğinizi bilmesini sağlayın .

Takımınla buluş. Takımınızda görmek istediğiniz davranışları modelleyin: alçakgönüllülük, saygı ve iyileştirme taahhüdü.

Şöyle bir şey söyleyin: “Bildiğiniz gibi, [iş arkadaşı] ve yakın zamanda yaşadığımız üretim sorunlarını önlemek için kod kalitesini sağlamakla görevlendirildim. Şahsen ben bu sorunu çözdüğümü sanmıyorum. Sanırım en büyük hatam, başlangıçta hepinizi daha fazla dahil etmek değildi. [arkadaşı] ve ben hala sorumlu birlikte kalite çaba hepsi, kod kalitesi için yönetime, ama ileriye gidecek.”

Ekipten kod kalitesi hakkında fikir edinin. (Bir beyaz tahta yardımcı olur.) İhtiyaçlarınızın sonuna kadar geldiğinden emin olun. Fikirlerinizi saygılı şekillerde sunun ve uygun olduğunda sorular sorun. Takımınızın önemli olduğunu düşündüğü şeyler konusunda şaşırmaya istekli olun. İş gereksinimlerinden ödün vermeden esnek olun.

(Eğer utandığınız eski bir kodunuz varsa, herkesi samimi olmaya teşvik ederek mahvedebilirsiniz, sonuçta, millete bunu yazdığınızı bildirin. Başkaları inşaat eleştirisi alırken umdukları olgun tepkiyi modelleyin. )

İşbirlikçi Kod İncelemeleri

Birkaç kıdemli programcının tüm kodu gözden geçirip düzeltmeler yaptığı, tarif ettiğiniz gibi bir yerde çalışmamıştım. İnsanların, kağıtları üzerinde kırmızı izler bırakan bir öğretmen gibi cevap vermelerine şaşmamalı.

Fikri yönetime satabiliyorsanız, eş kod incelemeleri yapmaya başlayın . Bu en iyi siz veya diğer sorumlu geliştirici de dahil olmak üzere küçük gruplar halinde yapılır. Herkese saygıyla davranıldığından emin olun.

Akran incelemesi kodunun önemli bir amacı, kodun ekibin tüm üyeleri tarafından anlaşılmasını sağlamaktır. Belirsiz işlev isimleri örneğini göz önünde bulundurun: daha küçük bir geliştiriciden işlev isminin kafa karıştırıcı olduğunu bulduklarını duymak, üst düzey geliştiriciden başka bir "düzeltme" den daha kolay kabul edilebilir.

Kalite bir yolculuktur

Yapılacak bir diğer şey, bir kod incelemesinin başarılı / başarısız bir şey olduğu fikrini ortadan kaldırmaktır. Herkes bir kod incelemesinden sonra bazı düzenlemeler yapmayı beklemelidir. (Ve işin onların olmasını sağlamak.)

Ama bu işe yaramazsa ...

Bir kalite kültürü oluşturan bazı adımlar attığınızı varsayalım. Hala herkesi uçağa atmayabilirsin. Eğer birisi hala kalite programında değilse, şimdi sorun, ikiniz arasında bir sorun olmaktan ziyade, takıma uymuyor olmalarıdır. Takımdan atılmaları gerekiyorsa, takımın geri kalanı nedenlerini daha iyi anlayacaktır.

Uzun bir cevap için özür dilerim, fakat diğerlerinin bu konunun insani unsurlarına tam olarak değindiklerini sanmıyorum.

bazen bir şeyin niçin belirli bir şekilde uygulandığını sormak bile. Kötü olduğunu düşündüğüm zaman, onu başka bir şekilde geliştireceğimi belirtiyorum.

"Neden bu şekilde uyguladın?" geliştiriciyi hemen savunmaya koydun. Sorunun kendisi içeriğe bağlı olarak her türlü şeyi ima edebilir: Daha iyi bir çözüm düşünemeyecek kadar aptal mısın? Yapabileceğin en iyi şey bu mu? Bu projeyi mahvetmeye mi çalışıyorsun? İşinizin kalitesini bile umursuyor musunuz? vb. Kodun niçin belirli bir şekilde geliştirildiğini sormak yalnızca yüzleşecek ve yorumunuzun sahip olabileceği herhangi bir pedagojik amacı altüst edecek.

Benzer şekilde, "Bunu farklı şekilde yapardım ..." aynı zamanda yüz yüze gelir, çünkü geliştiricinin sahip olacağı derhal " Bu şekilde yaptım ... Onunla bir sorunun mu var? " olması gerekir ve tartışmayı kodu iyileştirmekten uzaklaştırır.

Örnek:

Bunun yerine sorma "Neden bu değer için sabit değişken kullanmamayı tercih ettiniz?", Basitçe "Bu sabit kodlanmış değeri sabit değiştirilmelidir devlet XYZdosyasında Constants.hsoru geliştirici aktif seçti düşündürmektedir sorma" değil kullanmak önceden tanımlanmış bir sabittir, ancak var olduğunu bile bilmemeleri tamamen mümkündür. Yeterince büyük bir kod tabanına sahip, her geliştiricinin bilmediği birçok şey olacak. Bu, geliştiricinin projenin sabitlerini tanıması için iyi bir öğrenme fırsatıdır.

Kod incelemeleriyle yürümek için iyi bir çizgi var: söylediğiniz her şeyi şekerlemenize gerek yok, kötü haberi iyi haberlerle doldurmanıza gerek yok ve darbeyi yumuşatmanız gerekmez. İçinde bulunduğum kültür olabilir, ancak iş arkadaşlarım ve ben asla kod incelemelerinde iltifat etmiyoruz - geliştirdiğimiz kodun hatasız olan kısımları bir iltifat için yeterli. Yapmanız gereken şey, gördüğünüz kusuru tanımlamak ve belki de bir neden vermek (neden açık / basit olduğunda neden daha az kullanışlı).

İyi:

• "Bu değişkenin adının kodlama standartlarımızla eşleşmesi için değiştirilmesi gerekiyor."

• “Bu işlev adındaki 'b', PascalCase olabilmek için büyük harfle yazılmalıdır.”

• "Bu işlevin kodu doğru girintili değil."

• "Bu kod, bulunan kodun bir kopyası ABC::XYZ()ve bunun yerine bu işlevi kullanmalı."

• " Kaynaklarla denemeyi kullanmalısınız , böylece hatalar oluşsa bile bu fonksiyonda işlerin düzgün bir şekilde kapatılması garanti edilir." [Sadece buraya bir link ekledim, böylece java dışı kullanıcılar kaynakları denemenin ne demek olduğunu bilsinler]

• "N-yolundaki karmaşıklık standartlarımızı yerine getirmek için bu işlevin yeniden yapılandırılması gerekiyor."

Kötü:

• " Değişken adını standartlarımıza uyacak şekilde değiştirerek bu kodu geliştirebileceğinizi düşünüyorum "

• “ Belki de bu işlevdeki şeyleri düzgün bir şekilde kapatmak için kaynakla deneme özelliğini kullanmak daha iyi olur”

• " Belki bu işlevde her koşulda bir kez daha bakmak için arzu edilebilir. Onun N-yol karmaşıklığı bizim standardın izin verilen maksimum karmaşıklığı bitti."

• "Neden girintiler burada standardın 4 yerine 2 boşluk var?"

• “N-yolu karmaşıklık standartlarımızı ihlal eden bir fonksiyon neden yazdınız?”

Kötü ifadelerde, italikleştirilmiş parçalar, insanların darbeyi yumuşatmak istediklerinde yaygın olarak kullandıkları şeylerdir, ancak kod incelemesinde gerçekten tek yapmanız gereken, kendinizden emin olmamaktır. Siz, inceleyen, kodun nasıl geliştirileceğinden emin değilse, neden birileri sizi dinlesin?

'İyi' ifadeleri açıktır, ancak geliştiriciyi suçlamıyorlar, geliştiriciye saldırmıyorlar, yüzleşmiyorlar ve hatanın neden var olduğunu sorgulamıyorlar. Var; İşte düzeltme. Kesinlikle bu son 'neden' sorusu kadar çatışmacı değiller.

Gördüğünüz sorun şudur: Geliştiriciler kodlarının eleştirilmesinden memnun değildir. Ama sorun bu değil. Sorun, kodlarının iyi olmamasıdır (açıkçası kod incelemelerinizin iyi olduğu varsayılmaktadır).

Geliştiriciler kodlarını eleştiriyi kendine çekmekten hoşlanmazsa, çözüm kolaydır: Daha iyi kod yaz. Kod kalitesiyle ilgili ciddi problemleriniz olduğunu söylüyorsunuz; Bu daha iyi kod gerekli demektir.

“Neden yöntemin mantıklı bir adı olmalı, ne işe yaradığını biliyorum?” özellikle rahatsız edici bulduğum bir şey. Ne yaptığını biliyor ya da en azından öyle söylüyor, ama bilmiyorum. Herhangi bir yöntem yalnızca mantıklı bir isme sahip olmamalı, kodun okuyucusuna ne yaptığını derhal netleştirecek bir isme sahip olmalıdır. Apple'ın web sitesine gitmek ve Swift 2'den Swift 3'e yapılan değişiklikler hakkında bir WWDC videosu aramak isteyebilirsiniz - yalnızca her şeyi daha okunaklı hale getirmek için yapılan çok sayıda değişiklik. Belki de bu tür bir video, geliştiricilerinizi, kendisinden daha akıllı geliştiricilerin sezgisel yöntem adlarını çok, çok önemli bulmaya ikna edebileceğine ikna edebilir.

Rahatsız edici bir diğer konu da "Bana kendisinin, bir müşteri tarafından bir rapor gönderildikten sonra, hatayı bildiğini, ancak geliştiricinin işaret ettiği için ona kızacağından korktuğunu" söyleyen meslektaşınızdı. Bazı yanlış anlamaların olma olasılığı vardır, ancak bir hataya dikkat çekerseniz bir geliştirici sinirlenirse, bu kötüdür.

Tanımladığınız kod inceleme yöntemine saygıyla katılmıyorum. İki personel “kapalı bir oda” ya giriyor ve eleştiriyle ortaya çıkıyor , iyi kod incelemelerinin önlenmesi gerektiği konusunda çok büyük bir fikir ayrılığını kurumsallaştırıyor .

Kod incelemesini mümkün olduğunca olumlu bir deneyim haline getirmek, başarılı kılmak için esastır. Birinci adım, olumsuz inceleme fikrini ortadan kaldırmaktır. Haftalık ya da iki haftada bir grup etkinliği yapın; Herkesin katılmaya davetli olduklarını bilmelerini sağlayın. Pizza, sandviç ya da her neyse sipariş edin. Olumsuz çağrışımlar uyandırırsa, ona 'kod incelemesi' bile demeyin. Mevcut sprint veya yineleme boyunca ilerlemekten başka bir şey olmasa bile, kutlayacak, cesaretlendirecek, paylaşacak bir şey bulun. Sırayla gözden geçirme üzerinde liderlik görevini üstlen.

Süreci, ürüne ve halka hizmet etmek için bir çaba gösterin. Yapıcı ve olumlu bir şekilde yapılırlarsa, iyi tekniklerin veya kalıpların tıpkı fakirlerin cesareti kırıldığı gibi paylaşıldığı ve teşvik edildiği - herkes yararlanır. Herkes halka açıklanır. “Başlamayan” bir sorun programcınız varsa, özel ve ayrı ayrı ele alınmalıdır - asla daha geniş bir grubun önünde olmamalıdır. Bu kod incelemesinden ayrı.

Eğer ortaya çıkarmak için "iyi" bir şey bulmakta sorun yaşıyorsanız, bana bir soru sorar: Projede ilerleme kaydediliyorsa ve insanlar çalışıyorsa, bu ilerleme kendi içinde kutlanacak bir şeydir. Eğer gerçekten buluyoruz Eğer hiçbir şey iyi, bu son yorum ya olduğundan yapılmış her şeyi ima kötü veya daha iyi nötr . Durum gerçekten bu mu?

Ayrıntılar için ortak standartlar şarttır. Herkese ne yapıldığı konusunda bir pay ver. Ve daha yeni, daha iyi tekniklerin kod tabanınıza entegre edilmesine izin verin. Bunu yapmamak, eski alışkanlıkları garanti etmek için asla “biz her zaman böyle yaptık” kisvesi altında eksize edilmez.

Bütün bunların amacı, kod incelemelerinin biraz kötü bir rap yapmasıdır, çünkü kötü uygulanmaktadırlar, daha az deneyimli veya daha az yetenekli programcıların kırıcıları olarak kullanılırlar ve hiç kimseye hizmet vermezler. Bunları bu şekilde kullanan yöneticilerin de çok etkili yöneticiler olma ihtimali yoktur. Ürünün, çalışanların ve şirketin - herkesin katılımcı olduğu iyi kod incelemeleri.

Görev süresinin uzunluğu için özür diler, ancak kod incelemesinin büyük ölçüde göz ardı edildiği bir grupta yer alması, sürdürülemez bir kodun mirasına ve yıllarca sürecek bir kod tabanında değişiklik yapmasına izin verilse bile, yalnızca dar bir geliştirici yelpazesine neden oldu. Tekrar geçiş yapmamayı tercih ettiğim bir yoldu.

İyi kodun paradoksu, hiç göze çarpmaması ve yazması çok kolay ve basit görünüyor. Bu cevabın bilardo oyuncusu örneğini gerçekten seviyorum . Kod incelemelerinde, hatalı koddan kaynaklanan bir yeniden düzenleme aracı olmadıkça, kolayca parlatmayı kolaylaştırır.

Aramak için bir noktaya değindim. Eğer kodu gözden geçiriyorsam ve okunması kolay bir yazı yazmanın aldatıcı derecede kolay olduğunu düşündüğüm bir dosyadan geçtiysem, hızlıca "Buradaki yöntemlerin nasıl kısa ve temiz olduğunu seviyorum" ya da ne olursa olsun .

Ayrıca, örnek olarak liderlik etmelisin. Kodunuzun da gözden geçirilmesi konusunda ısrar etmeli ve düzeltme alırken ekibinizin nasıl davranmasını istediğinizi modellemelisiniz. En önemlisi, geri bildirim için insanlara içtenlikle teşekkür etmelisiniz. Bu, verebileceğiniz tek taraflı geri bildirimlerden daha fazla fark yaratır.

Gerçek sorun gibi görünüyor ki, tüm kod incelemelerini yapan sadece iki kişi, sadece onları ciddiye alan sensin, bu da sizi çok fazla sorumluluk alan ve çok fazla talihsiz bir durumda sonuçlandıran diğer takım üyelerinden gelen baskı.

Daha iyi bir yol, kod incelemelerini ekipte yapma sorumluluğunu dağıtmak ve örneğin geliştiricilerin kodunu kimlerin inceleyeceğini seçmelerine izin vererek herkesin bunları yapmada yer almasını sağlamaktır. Bu, kod inceleme aracınızın desteklemesi gereken bir şeydir.

Bunun ilk elden olduğunu gördüm ve sizi duygusal zeka sorunlarından uzak tutmak için uyarmak istiyorum - tüm ekipleri öldürebilirler. Her yıl yeni geliştiricileri işe almak, eğitmek ve normalleştirmek istemiyorsanız, meslektaşlarınızla olumlu bir ilişki kurmak çok önemlidir. Her şeyden önce, kod kalitesini iyileştirmek ve ilk olarak kod kalitesinin yüksek olduğu bir kültürü geliştirmek için bu incelemeleri yapmanın asıl amacı yok mu? Bu kod inceleme sistemini takım kültürüne entegre etmenin bir aracı olarak pozitif güçlendirme sağlamanın işinizin bir parçası olduğunu savunuyorum.

Neyse, Kod İnceleme sisteminizi incelemeniz gerektiği gibi sesler. Şu anda, seslerinizden inceleme sürecinizdeki her şey objektif olmaktan ziyade öznel olarak yorumlanabilir veya yorumlanabilir. Birisi kurallara uymuyorsa, bir şeyi kurallara uymadığı zaman aktarabilecekleri bir neden olmaktan ziyade, sadece kodunuzu seçmek gibi hissettiğinde incinmiş hissetmek kolaydır. Bu şekilde, kod kalitesindeki (gözden geçirme sisteminize göre) olumlu gelişmeleri ofis kültürünüz için uygun olan şekilde izlemek ve 'kutlamak' kolaydır.

Teknik Liderler bir inceleme oturumu dışında bir araya gelmeli ve bir Kodlama Kuralları / Kod İnceleme Kontrol Listesi hazırlamalı ve inceleme sırasında uyulması ve yönlendirilmesi gerekir. Bu, süreç ilerledikçe güncellenebilecek ve rafine edilebilecek canlı bir belge olmalıdır. Bu Teknik Kurşun toplantıları aynı zamanda “Her zaman bir şeyi yapma şeklimiz” ile “Bir şeyler yapmanın yeni ve geliştirilmiş yolları” tartışmaları yapılmalıdır, geliştiricinin anlaşmazlığı olduğu gibi anlaşmazlığın kodunun bir sonucu olduğu düşünülmelidir. İlk rehber az çok yumuşatıldıktan sonra, geliştiricilerin olumlu yönde pekiştirilmesinin bir başka yolu geri bildirimlerini istemek ve daha sonra gerçekten harekete geçmek ve süreci bir ekip olarak geliştirin; bu, onboard'lar için kodu incelemeye başlama hızlarını artırmalarını sağlar, böylece emekli olana kadar inceleme yapmaktan mahrum kalmazsınız.

Tesisler ...

Programcılar problem çözücülerdir. Bir sorun veya hata ile sunulduğunda hata ayıklamaya başlamamız şarttır.

Kod, anahat biçiminde bir ortamdır. Paragraf formatlı bir anlatıya geri bildirim için geçiş yapılması, çevrilmesi gereken bir bağlantı kesilmesi sağlar. Kaçınılmaz olarak bir şey kaybolur veya yanlış anlaşılır. Kaçınılmaz olarak, gözden geçiren programcının dilinde konuşmuyor.

Bilgisayar tarafından oluşturulan hata mesajları nadiren sorgulanır ve asla kişisel bir hakaret olarak alınmaz.

Kod gözden geçirme öğeleri, insan tarafından oluşturulan hata mesajlarıdır. Diğer program ve veriler üzerinde kaçınılmaz yan etkilerin yanı sıra programcıların ve otomatik araçların kaçırdığı son durumları yakalamaları amaçlanmaktadır.

Sonuçlar ...

Bu nedenle, kod gözden geçirme öğeleri otomatik araçlara ne kadar çok dahil edilirse, o kadar iyi alınacaktır.

Uyarı, sorgulanmamak üzere, bu tür araçların prosedürlerde, standartlarda ve uygulamalarda yapılan her değişiklikle uyumlu olması için genellikle günlük veya haftalık olarak sürekli güncellenmesi gerektiğidir. Bir yönetici veya geliştirici ekip değişiklik yapmaya karar verdiğinde, bunu uygulamak için araçlar değiştirilmelidir. Kod gözden geçirenin işinin çoğu, araçlardaki kuralları korur hale gelir.

Örnek Kod İnceleme Geri Bildirimi ...

Bu teknikleri içeren verilen örneğin yeniden yazılması:

• Konu, özne:

  • Library \ ACME \ ExtractOrderMail Class.

• İlke sorunu ...

  • TempFilesToDelete statiktir
    • Daha sonra GetMails'e yapılan çağrılar, dosyalar kendisine eklendiğinden ancak silindikten sonra kaldırılmadığından bir istisna atar. Şimdi sadece bir çağrı olsa da, gelecekte bazı paralelliklerle performans geliştirilebilir.
    • Bir örnek değişkeni olarak TempFilesToDelete, birden çok nesnenin paralel olarak kullanılmasına izin verir.
• İkincil konular ...
  • GetErrorMailBody bir istisna parametresi var
    • Bir istisna atmadığı ve bunu sadece ToString'e ilettiği için gerekli mi?
  • SaveAndSend adı
    • E-posta, gelecekte bunu bildirmek için kullanılabilir veya kullanılmayabilir ve bu kod kalıcı bir kopyayı saklamak ve hataları bildirmek için genel bir mantık içerir. Daha genel bir isim, bağımlı yöntemlerde değişiklik yapılmadan beklenen değişikliklere izin verir. Bir olasılık StoreAndReport.
  • Eski kodu yorumlayarak
    • Yorumlanmış ve işaretlenmiş bir çizgiyi terk etmek hata ayıklamada çok yardımcı olabilir, ancak "yorum duvarı" bitişik koddaki hataları da gizleyebilir. Hala Subversion'da var. Belki de sadece Subversion'da tam olarak nereye atıfta bulunan bir yorum?

Mevcut kod hakkında söylenebilecek hoş bir şeyiniz yoksa (anlaşılabilir sesler), geliştiriciyi geliştirmeye dahil etmeye çalışın.

İşlevsel bir değişiklik veya hata düzeltme için bir düzeltme ekinde, aynı düzeltme ekinde bir araya getirilmiş başka değişikliklerin (yeniden adlandırma, yeniden düzenleme, ne olursa olsun) yapılması yararlı değildir. Bu hatayı düzelten ya da özelliği ekleyen bir değişiklik yapmalı, başka bir şey yapmamalı.

Adlandırma, yeniden düzenleme ve diğer değişiklikler Nerede edilir belirtilen önce veya sonra, ayrı bir yama bunları yapmak.

• Bu oldukça çirkin, ama sanırım diğer tüm kötü kurallarımızla tutarlı. Bunu daha sonra temizleyelim (ideal olarak, işlevsel bir değişiklik yapmadan).

  Eğer Üstlenmeden katılacak ve izin verirsen o da yardımcı olur onları gözden sizin kodu. Neden bir şeylerin kötü değil de iyi olduğunu düşündüğünüzü söyleme ve yapıcı eleştiriyi iyi örnekleme gösterme şansını veriyor.

Yeni bir özelliğe birim testleri eklemeniz gerekirse, sorun olmazsa ana yamaya giderler. Eğer bir hata tamir ediyoruz Ama eğer testler öncesinde yama gitmeli ve geçemiyor sen düzeltme aslında hata düzeltildi göstermek böylece.

İdeal olarak, plan (nasıl bir düzeltmeyi nasıl test edeceğiniz ya da ne zaman yeniden düzenleyeceğinize yönelik olarak) çalışma yapılmadan önce tartışılmalıdır, bu yüzden bir problem yaşamaya başlamadan önce bir şey için çaba harcamadılar.

Kod bulmanız gerektiğini düşündüğünüz girdilerle başa çıkmazsa, geliştiricinin makul girdi olarak gördüğü bir uyumsuzluk da olabilir. Mümkünse, bunu da önceden kabul edin. En azından neyle başa çıkabileceğini ve ne kadar acımasızca başarısız olmasına izin verilebileceği hakkında biraz tartışma yapın.

Bence teknik veya kolay bir çözüm olduğunu varsaymak yanlıştır: "çalışma arkadaşlarım çalışmalarını standartlarım ile değerlendirdiğimde üzülürler ve bunu uygulamada bazı güçler vardır".

Unutmayın, kod incelemeleri sadece neyin iyi neyin kötü olduğu ile ilgili bir tartışma değildir. Örtük bir şekilde "kimin kullandığı" biz kullanıyoruz "," bir "kararı veren" ve dolayısıyla en sinsice - bir rütbe.

Bu noktaları ele almazsanız, kod incelemelerini karşılaştığınız sorunlarla karşılaşmayacak şekilde yapmak zor olacaktır. Burada bunun nasıl yapılacağı hakkında bazı iyi tavsiyeler var, ancak kendinize zor bir görev belirlediniz.

Haklıysanız, herhangi bir kıkırdama odası olmadan, işaret etmek bir saldırıdır: birisi berbat etti. Değilse: alamayan başka bir MBA'iniz. Her iki durumda da, kötü adam olacaksın.

Bununla birlikte, gözden geçirmenin neye baktığını ve niçin , açık ve anlaşılırsa, kötü adam olmamanın iyi bir şansı var. Sen kapı bekçisi değilsin, sadece bir prova okuyucusu. Bu anlaşmanın alınması, çözülmesi zor bir problemdir [1]. Sana bir tavsiyede bulunmak isterdim ama henüz kendimden haber alamadım.

[1] Sorun çözülmedi çünkü insanlar "tamam" demişti ya da bunun için savaşmayı kesti. Hiçbiri, X'in {istihbarat, tecrübe, insan gücü, son teslim tarihleri, vb.) İçin pratik olmadığını söyleyen biri olmak istemiyor ama bu aslında X yapmanın belirli bir örneğine gelince ...

Kod incelemeleri karşılıklı olmalıdır. Herkes herkesi eleştirdi. Sloganı "kızma, hatta alma" olsun. Herkes hatalar yapar ve insanlar sıcak bir atış kodlarını nasıl çözeceklerini söylediklerinde, bunun normal bir prosedür olduğunu ve onlara yapılan bir saldırıyı anlayamayacaklarını anlarlar.

Başkalarının kodunu görmek eğitimdir. Kodu, zayıf noktasını işaret edebileceğiniz noktaya kadar anlamak ve zayıflığın size çok şey öğretebileceğini açıklamak zorundasınız !

Önemli olan nokta bulmak için kod incelemesinde övgüye çok az yer var. Ancak, övgüleri düzeltmelerle öbekleyebilirsiniz . Hem zamanındalık hem de düzenli olma övgüyle söz edilebilir.