Olası bir dava ile ilgili bir kod incelemesinde anlaşmazlığı nasıl ele alabilirim?

Bir yol kapsama ekibinde robotik bir başlangıçta çalışıyorum ve çekme isteği gönderdikten sonra kodum inceleniyor.

Bir yıldan fazla bir süredir takımda olan takım arkadaşım, gerekli olduğuna inandığımdan çok daha fazla iş yaptığımı öneren koduma bazı yorumlar yaptı. Hayır, tembel bir geliştirici değilim. İyi yorumlara, değişken isimlere, girintilere sahip ve zarif vakalara sahip zarif kodları seviyorum. Bununla birlikte, aynı fikirde olmadığım akılda farklı bir organizasyon türü var.

Bir örnek vereceğim:

Yaptığım bir geçiş bulma algoritmasındaki bir değişiklik için test senaryoları yazmak için bir gün geçirdim. Olması muhtemel olmayan karanlık bir olayı ele almamı önerdi - bunun gerçekleşmesinin bile mümkün olduğundan emin değilim. Yaptığım kod zaten orijinal test senaryolarımızın hepsinde ve bulduğum bazılarında çalışıyor. Yaptığım kod zaten gece çalıştırılan 300'den fazla simülasyonumuzu geçiyor. Ancak, bu belirsiz durumun üstesinden gelmek, robotun performansını iyileştirmeye çalışırken daha iyi harcanabilecek 13 saatimi alacaktır. Açık olmak gerekirse, şu ana kadar kullandığımız önceki algoritma da bu karanlık olayı ele almadı ve bir kez değil, oluşturulan 40k raporlarında, hiç olmadı. Biz bir girişimiz ve ürünü geliştirmemiz gerekiyor.

Daha önce hiç kod incelemem olmadı ve çok tartışmacı olup olmadığımdan emin değilim; Sadece sessiz olmalı mıyım ve ne diyorsa yapmalı mıyım? Kafamı tutmaya karar verdim ve sadece zamanın iyi bir şekilde kullanıldığına kesinlikle katılmıyorum olsa da değişiklik yapmaya karar verdim.

İş arkadaşıma saygı duyuyorum ve onu akıllı bir programcı olarak kabul ediyorum. Sadece bir konuda ona katılmıyorum ve bir kod incelemesinde anlaşmazlığın nasıl ele alınacağını bilmiyorum.

Seçtiğim cevabın, küçük bir geliştiricinin kod incelemesinde anlaşmazlıkla nasıl başa çıkabileceğini açıklamak için bu kriterleri karşıladığını hissediyorum.

gerçekleşmesi muhtemel olmayan karanlık bir vaka - aslında bunun gerçekleşmesinin bile mümkün olduğundan emin değilim.

Kodda denenmemiş davranışlara sahip olmamak çok önemli olabilir. Örneğin, saniyede 50 kez bir kod parçası çalıştırılırsa, yaklaşık her 5.5 saatlik çalışma süresinde bir milyon şansı olan bir tane olur. (Senin durumunda, oran düşük görünüyor.)

Öncelikleri hakkında müdürünüzle konuşabilirsiniz (veya çalıştığınız birim için daha kıdemli bir kişi kim varsa). Örneğin, kod performansı üzerinde çalışmak veya kurşun geçirmez olmak için kod üzerinde çalışmak en önemli önceliktir ve bu köşe durumunun ne kadar mümkün olamayacağını daha iyi anlayacaksınız. Gözden geçiren kişinin de öncelikler konusunda çarpık bir fikri olabilir. Sorumlu kişiyle konuştuktan sonra, gözden geçiren önerilerinize katılarak daha kolay bir zaman (dis) olacak ve başvuracak bir şeyiniz olacaktır.

Birden fazla gözden geçirene sahip olmak her zaman iyi bir fikirdir. Kodunuz yalnızca bir meslektaş tarafından incelenirse, bu kodu veya genel olarak kod tabanını bilen bir başkasına bir göz atmasını isteyin. İkinci bir görüş, yine, gözden geçirenin önerilerini daha kolay (dis) kabul etmenize yardımcı olacaktır.

Birkaç kod incelemesi sırasında tekrar eden birçok yoruma sahip olmak genellikle daha açık bir şekilde iletişim kurulmamasına işaret eder ve aynı konular tekrar tekrar ortaya çıkar. Daha büyük olanı bulmaya çalışın ve doğrudan gözden geçirenle görüşün. Neden soru sormak yeterli . Kod incelemesi uygulamasına başladığımda bana çok yardımcı oldu.

Size felakete neden olacak asla oluşamayacak bir köşe davası örneği verebilirim.

Ne zaman Ariane 4 yanal değerleri geliştirilen ediliyordu accelerometers bir sığmayacak ölçekli edildi 16 bitlik işaretli tamsayı ve ivmeölçerlerin mümkün olan maksimum çıkış, ölçeklenebilir zaman, çünkü hiçbir zaman 32767 aşan aşan ve asgari olabilir asla altına düşmemesi - 32768 “aralık kontrolünün ek yüküne gerek yok” vardı. Genel olarak, tüm girdilerin herhangi bir dönüştürme işleminden önce aralıklarla kontrol edilmesi gerekir, ancak bu durumda bu imkansız bir köşe davası yakalamaya çalışır.

Birkaç yıl sonra Ariane 5 geliştirildi ve lateral ivmeölçerlerin ölçeklendirilmesi için kod “kullanımda kanıtlanmış” olduğu gibi minimum testlerle yeniden kullanıldı. Maalesef, daha büyük olan roket daha büyük yanal ivmeler bekleyebilir, böylece ivmeölçerler yükseltilmiş ve daha büyük 64 bitlik şamandıra değerleri üretebilmiştir .

Bu daha büyük değerler dönüşüm koduna "sarılmış", aralık kontrolü olmadığını hatırlıyor ve 1996'daki ilk lansmandaki sonuçlar iyi değildi. Şirkete milyonlara mal oldu ve programda büyük bir ara verdi.

Yapmaya çalıştığım nokta, test senaryolarını hiç olmadıkça, son derece düşük olasılıkla vb. Görmezden gelmemelisiniz. Kodlama için girdikleri standartlar, tüm harici giriş değerlerinin aralık kontrolü için çağrıldı . Eğer bu test edilmiş ve kullanılmışsa, felaket önlenmiş olabilir.

Not Ariane 4'te bu, bir hata olmadığını (her şeyin mümkün olan her değeri için iyi çalıştı gibi) - standartları takip etmek başarısız oldu. Kod farklı bir senaryoda yeniden kullanıldığında, felaketsel bir şekilde başarısız oldu, eğer değerler aralığı kırpılmışsa, büyük olasılıkla incelikli bir şekilde başarısız olmuş olacaktı ve bunun için bir test vakasının varlığı , değerlerin gözden geçirilmesini tetiklemiş olabilirdi . Ayrıca, kodlayıcılar ve test uzmanlarının patlamanın ardından araştırmacılardan bazı eleştiriler için gelmelerine rağmen, yönetim, KG ve liderliğin suçlamanın büyük çoğunluğu ile kaldığını belirtmek gerekir.

açıklama

Her ne kadar tüm yazılımlar güvenlik açısından kritik olmasa da, ne zaman başarısız olursa o kadar muhteşem olmasa da, niyetim "imkansız" testlerin hala değerli olabileceğini vurgulamaktı. Bu bildiğim en dramatik durum ama robotik de bazı felaket sonuçlar doğurabilir.

Şahsen, birileri test ekibine bir köşe davası seçtiğinde, onu kontrol etmek için bir test yapılması gerektiğini söyleyebilirim. Uygulama ekibi lideri veya proje yöneticisi , bulunan hataları gidermeye çalışmamaya karar verebilir, ancak eksikliklerin olduğunu bilmelidir. Alternatif olarak, eğer test yapmak için çok karmaşıksa veya pahalıysa, test edilen kullanımda ve / veya risk kayıt defterinde bu durumun test edilmemiş bir durum olduğunu açıkça ortaya koymak için bir sorun ortaya çıkabilir - ve bunun ele alınması gerekebilir. kullanım değişikliğinden önce veya uygunsuz kullanımı önleyin.

Daha önce ele alınmadığından, çabanızın kapsamı dışında. Siz veya meslektaşınız müdürünüze bu davayı ele alma çabasına değip değmeyeceğini sorabilir.

Karmaşık algoritmalarla, gerçek dünyada ortaya çıkacak her test vakası hakkında düşündüğünüzü kanıtlamak çok zor. Gerçek dünyada ortaya çıkmayacağı için kasıtlı olarak bir test vakasını kırık bıraktığınızda, potansiyel olarak henüz düşünmemiş olduğunuz diğer test senaryolarını kırıyorsunuzdur.

Sık sık ortaya çıkan diğer etki, ek test durumlarını ele aldığınızda, algoritmanızın mutlaka daha genel hale gelmesidir ve bu nedenle basitleştirmenin ve tüm test durumlarınız için daha sağlam hale getirmenin yollarını bulmanız gerekir. Bu size bakım ve yolda sorun giderme konusunda zaman kazandırır.

Ayrıca, vahşi doğada meydana gelen "bu asla gerçekleşmemeli" hataların sayısız vakası vardır. Bunun nedeni, algoritmanızın değişmeyebileceği, ancak hiç kimse bu işlenmemiş kullanım durumunu hatırlamadığında, girdiler yıllar boyu değişebilir. Bu nedenle tecrübeli geliştiriciler, zihinlerinde taze olduklarında bu tür şeylerle başa çıkmaktadır. Yapmazsan seni daha sonra ısırmaya gelir.

Bu teknik bir soru değil, bir iş stratejisi kararıdır. Önerilen düzeltmenin, neredeyse hiç olmayacak olan çok karanlık bir vaka için olduğunu fark ettiniz . Burada bir oyuncak programlıyorsanız veya tıbbi ekipman veya silahlı bir dron diyorsanız programlayın. Nadir bir arıza sonucu çok farklı olacaktır.

Kod incelemeleri yaparken, nadir durumlarda ele almaya ne kadar yatırım yapacağınıza karar verirken iş öncelikleri hakkında temel bir anlayış uygulamalısınız. Meslektaşınıza işin önceliklerini yorumlama konusunda katılmıyorsanız, işin iş tarafındaki biriyle görüşmek isteyebilirsiniz.

Kod incelemeleri tamamen kod doğruluğu ile ilgili değildir. Gerçekte, bu, bilgi paylaşımının ve ekip tarzı / tasarım konsensüsünün yaratılmasına yönelik yavaş ama istikrarlı bir süreç olmanın arkasında, fayda listesinin oldukça aşağısındadır.

Siz yaşadıkça, "doğru" sayılan şey çoğu zaman tartışılabilir ve herkesin ne olduğuna dair kendi açısı var. Tecrübelerime göre, sınırlı zaman ve dikkat, kod incelemelerini oldukça tutarsız hale getirebilir - aynı sorun, farklı geliştiricilere ve aynı zamanda aynı geliştirici tarafından farklı zamanlarda ele alınabilir. "Bu kodu ne geliştirir?" genellikle doğal olarak kendi çabalarına katmayacakları değişiklikler önerecektir.

Deneyimli bir kodlayıcı olarak (geliştirici olarak 15 yıldan fazla), benden daha az yıllık deneyime sahip kodlayıcılar tarafından sık sık incelenirim. Bazen benden hafifçe aynı fikirde olmadığım veya önemsiz düşündüğüm değişiklikler istiyorlar. Ancak yine de bu değişiklikleri yapıyorum. Sadece nihai sonucun üründe bir zayıflığa neden olacağını, zaman maliyetinin çok yüksek olduğu ya da "doğru" bir bakış açısının nesnelleştirilebileceği durumlarda (örn. Değişiklik için kazanılmasının istendiği gibi) değişiklikler konusunda savaşımla mücadele ediyorum. t Kullanmakta olduğumuz dilde çalışmak, ya da bir kıyaslama iddia edilen performans iyileştirmenin bir olmadığını gösteriyor).

Bu yüzden savaşlarınızı dikkatlice seçmenizi öneririm. Gerekmediğini düşündüğünüz bir test olayını kodlayan iki gün, muhtemelen mücadele etmek için zaman / çabaya değmez. GitHub çekme istekleri gibi bir inceleme aracı kullanıyorsanız, itirazınızı not etmek, ancak yine de çalışmayı kabul etmek için, belki de algıladığınız maliyet / fayda hakkında yorum yapın. Bu, nazik bir geri çekilme olarak sayılır, bu nedenle gözden geçiren kişi bir sınıra çarptıklarını bilir ve daha da önemlisi gerekçenizi de içerir; böylece bu gibi durumlar kilitlenmeye başlarsa yükseltilebilir. Yazılı anlaşmazlıkları tırmandırmaktan kaçınmak istersiniz - iş farkları konusunda bir Internet forumu tarzı tartışması yapmak istemezsiniz - bu nedenle ilk önce konuyu konuşmak ve tartışmanın sonucunun adil bir özetini kaydetmek faydalı olabilir,dostça tartışma zaten sizin için karar verecek.

Etkinlikten sonra, bu sprint incelemesi veya geliştirme ekibi planlama toplantıları vb. İçin iyi bir konudur. Örneğin, "Kod incelemesinde, Geliştirici A bu ek test vakasını tanımladı, yazması fazladan iki gün sürdü, Ekip, ekstra teminatın bu maliyete haklı olduğunu düşünüyor mu? " - eğer bu işi gerçekten yaparsanız, size olumlu bir ışık gösterdiği gibi bu yaklaşım daha iyi çalışır; işi yaptınız ve takımı riskten kaçınma ve özellik geliştirme için sorgulamak istiyorsunuz.

En azından belirsiz davaya karşı çıkmanızı öneririm. Bu şekilde, yalnızca gelecekteki geliştiriciler, davaya karşı aktif olarak karar verdiğinizi görmemekle kalmaz, aynı zamanda yerinde olması gereken iyi bir başarısızlık yönetimi ile bu da sürprizlerle karşılaşır.

Ve sonra, bu başarısızlığı iddia eden bir test davası yapın. Bu şekilde, davranış daha iyi belgelenir ve birim testlerinde ortaya çıkar.

Bu cevap, açıkça “mümkün olsa bile son derece düşük ihtimal” olduğuna dair yargınızın doğru olduğunu ve bunu yargılamayacağımızı varsayar. Ancak öyleyse ve meslektaşınız da kabul ederse, olaya karşı açık bir iddia her ikiniz için de tatmin edici bir çözüm olmalıdır.

Orada yeni gözüktüğünüz için yapabileceğiniz tek şey var - takım lideri (veya proje lideri) ile kontrol etmek. 13 saat bir iş kararıdır; Bazı firmalar / takımlar için çok fazla; bazıları için, hiçbir şey. Bu senin kararın değil, henüz değil.

Lider "bu davayı kapat" diyorsa, sorun değil; eğer "hayır, boşver" diyorsa, para cezası - kararı, sorumluluğu.

Genel olarak kod incelemelerine gelince, rahatlayın. Bir veya iki defa size bir görevin iade edilmesi tamamen normaldir.

SteveBarnes cevabında biraz gündeme gelmesine rağmen nazikçe hitap ettiğimi sanmadığım bir şey:

Bir başarısızlığın yansımaları nelerdir?

Bazı alanlarda bir başarısızlık web sayfasındaki bir hatadır. Bir PC mavi ekranlar ve yeniden başlatır.

Diğer alanlarda yaşam ya da ölümdür - kendi kendini süren araba kilitlenir. Tıbbi tempo üreticisi çalışmayı durdurur. Veya Steve'in cevabında: Milyonlarca dolar kaybına neden olan şeyler patlar.

Bu uçlarda farklı bir dünya var .

Bir "başarısızlığı" örtbas etmek için 13 saatin geçip geçmemesi sonuçta size değmez. Yönetim ve sahiplerine kalmalıdır. Büyük resim için bir hisleri olmalı.

Buna değecek şeyin ne olduğuna dair iyi bir tahminde bulunabilmelisiniz. Robotunuz yavaşlar mı yoksa durur mu? Düşük performans? Yoksa robotun arızalanması, maddi hasara neden olur mu? Hayat kaybı?

Bu sorunun cevabı, "şirketlerin 13 saat sürmesine değer mi" cevabını vermelidir. Uyarı: Şirketler zamanı dedim. Faturaları ödüyorlar ve nihayetinde buna değer olduğuna karar veriyorlar. Yönetiminiz son söyleyebilecek şekilde olmalı.

İşe öncelik vermekten sorumlu olan kişiyle konuşabilir miyiz? Başlangıçta CTO veya ürün sahibi olabilir. Bu fazladan çalışmanın gerekli olup olmadığını ve nedenini bulmakta yardımcı olabilir. Ayrıca günlük stand-up sırasında endişelerinizi getirebilirsiniz (eğer varsa).

İş planlaması konusunda net bir sorumluluk (örneğin ürün sahibi) yoksa, etrafınızdaki kişilerle konuşmaya çalışın. Daha sonra herkesin ürünü ters yöne ittiği bir sorun haline gelebilir.

Küçük bir geliştirici veya kıdemli bir geliştirici veya bir CEO olsanız da, anlaşmazlığı çözmenin en iyi yolu aynıdır.

Columbo gibi davran .

Eğer hiç Columbo izlememişseniz, oldukça fantastik bir şovdu. Columbo bu alçakgönüllü bir karakterdi - çoğu insan biraz çılgınca olduğunu ve endişelenmeye değer olmadığını düşünüyordu. Ama mütevazı görünerek ve insanlardan sadece açıklamalarını isteyerek erkeğini elde etmeyi başardı.

Bunun Sokratik yöntemle de ilgili olduğunu düşünüyorum .

Genel olarak, doğru seçimleri yaptığınızdan emin olmak için kendinize ve başkalarına sorular sormak istersiniz. "Haklıyım, haksızsınız" pozisyonundan değil, dürüst bir keşif pozisyonundan. Ya da en azından olabildiğince iyi.

Senin durumunda, burada iki fikrin var, ama temelde aynı amacı var: kodu daha iyi hale getirmek.

Potansiyel olarak olanaksız olan (imkansız?) Bir durum için diğer özelliklerin geliştirilmesi lehine kod kapsamına girme ihtimalinin altındasınız, bunu yapmanın en iyi yoludur.

İş arkadaşınız, köşe davaları konusunda daha dikkatli olmanın daha değerli olduğu izlenimini uyandırıyor.

Görmediğin şeyi ne görüyorlar? Görmediklerini ne görüyorsun? Küçük bir geliştirici olarak aslında mükemmel bir konumdaysınız çünkü doğal olarak sorular sormalısınız. Başka bir cevabında biri bir köşe durumda ne kadar şaşırtıcı bir şekilde muhtemel olduğundan bahseder. Böylece, “Yardım etmeme yardım et - X, Y ve Z izlenimi altındaydım - neyi özlüyorum? Swizzle stick aslında ANZA fırçalarını içeriyor mu? "

Varsayımlarınızı ve bulgularınızı sorgularken kazıp çıkaracaksınız, önyargıları ortaya çıkaracak ve sonunda doğru eylemin ne olduğunu çözeceksiniz.

Takımınızdaki herkesin oldukça rasyonel olduğu ve sizin gibi ekibin ve ürünün aklındaki çıkarları en iyi olduğu varsayımıyla başlayın. Mantıklı olmayan bir şey yapıyorlarsa, ne yaptığını bilmediğinizi ya da ne anlamadığını bildiğinizi çözmeniz gerekir.

13 saat çok büyük bir iş değil, sadece yaparım. Unutma bunun için para alıyorsun. Sadece "iş güvenliği" olarak işaretleyin. Ayrıca takım arasında iyi bir karma olmak en iyisidir. Şimdi sizi bir hafta ya da daha fazla sürecek bir şey olsaydı, o zaman müdürünüze dahil olabilir ve ona zamanın en iyi kullanımının olup olmadığını sorabilirdiniz, özellikle de aynı fikirde değilseniz.

Ancak, grubunuzdaki kaldıraca ihtiyaç duyduğunuz gibi ses çıkarıyorsunuz. İşte nasıl kaldıraç kullanacağınız: affetmeyi isteyin izin istemeyin. Programa uygun gördüğünüz şeyleri ekleyin (kurs kapsamı dahilinde, yani patronun istediği sorunu tamamen çözdüğünden emin olun) ve yöneticiye veya meslektaşlarınıza durumdan sonra söyleyin. Onlara sorma: "X özelliğini eklersem sorun olmaz". Aksine, sadece programda kişisel olarak istediğiniz özellikleri ekleyin. Yeni bir özelliğe kızarlarsa veya aynı fikirde olmazlarsa, kaldırmayı tamamlayın. Eğer beğenirlerse, sakla.

Ek olarak, bir şey yapmanı istediklerinde, "ekstra mil" e git ve bahsetmeyi unuttukları veya söylediklerinden daha iyi çalışacak şeyler ekle. Ama onlara fazladan mil kullanmanın "iyi" olup olmadığını sorma. Sadece yapın ve yaptıktan sonra bunları rasgele söyleyin. Yaptığın şey onları eğitmek ..

Olan bu olacak menajeriniz sizi bir "alıcı" olarak görecek ve size olan güvenini vermeye başlayacak ve meslektaşlarınız sizi programa sahip olmaya başladığınız öncü olarak görmeye başlayacak. Ve sonra, bahsettiğiniz şeyler gelecekte meydana geldiğinde, daha çok söyleyeceksiniz, çünkü aslında takımın yıldızı sizsiniz ve onlarla aynı fikirde değilseniz, geri döneceksiniz.

Kod incelemesi çeşitli amaçlara hizmet eder. Açıkça farkında olduğunuz bir tanesi, " Bu kod amaç için uygun mu? ", Başka bir deyişle, işlevsel olarak doğru mu; yeterince test edildi mi? açık bir şekilde yorum yapılan açık olmayan bölümlerdir; projenin sözleşmelerine uygun mu?

Kod incelemesinin bir diğer bölümü sistem hakkındaki bilginin paylaşılmasıdır. Hem yazar hem de hakem için değiştirilen kodu ve sistemin geri kalanıyla nasıl etkileşime girdiğini öğrenmek için bir fırsattır.

Üçüncü bir özellik, herhangi bir değişiklik yapılmadan önce var olan sorunların bir incelemesini sağlayabilmesidir. Oldukça sık, bir başkasının değişikliklerini incelerken, önceki bir yinelemede özlediğim bir şeyi (genellikle kendi başıma gelen bir şeyi) görürüm. "İşte bunu olduğundan daha güçlü hale getirme fırsatı" gibi bir eleştiri, bir eleştiri değil ve bir olarak kabul etme!

Şu anki ekibim kod incelemesini sadece taahhütten önce kodun geçmemesi gereken bir ağ geçidi veya engel olarak değil, aynı zamanda belirli bir işlevsellik alanının yapılandırılmış bir tartışması için bir fırsat olarak görüyor. Bilgi paylaşımı için en üretken fırsatlardan biri. (Ve bu, her zaman aynı gözden geçiriciden ziyade, gözden geçirmeyi ekibin etrafında paylaşmak için iyi bir neden).

Kod incelemelerini bir yüzleşme etkinliği olarak algılarsanız, bu kendi kendine yeten bir kehanet demektir. Bunun yerine onları çalışmanızın en işbirlikçi parçası olarak görürseniz , ürününüzde ve birlikte çalışma şeklinizde sürekli iyileştirmeleri teşvik edeceklerdir. Bir gözden geçirmenin önerilerinin göreceli öncelikleri konusunda net olup olmadığına yardımcı olabilir - xörneğin, "Burada yararlı bir yorum istiyorum" ile "Bu hiç olumsuzsa bu aralar" arasında bir fark var .

Yukarıda birçok genel ifade verdikten sonra, bu sizin özel durumunuza nasıl uygulanır? Umarım artık tavsiyem incelemeye açık sorularla cevap vermek ve hangi yaklaşımın en değerli olduğunu tartışmaktır . Ek bir testin önerildiği örnek bir dava için, "Evet, bunun için test edebiliriz; uygulamanın <zaman> alacağını tahmin ediyorum . Bunun yararına değer olduğunu düşünüyor musunuz? Testin gerekli olmadığından emin olmak için ne yapabilir?

Sorunuzu okuduğumda beni vuran tek şey: yeni bir test davası yazmak iki gün sürecekse, yeni testiniz mevcut testlerinizden çok farklı bir senaryodur (bu durumda muhtemelen çok fazla olabilir.) değer) veya test paketinde yeniden kod kullanımının iyileştirilmesi için bir ihtiyaç tespit ettiniz.

Son olarak, kod incelemelerinin değeri hakkında genel bir yorum olarak (ve yukarıda söylediklerimin özlü bir özeti olarak), Daniel Vetter'ın Bakımcı Ölçeği'nde bu ifadeyi beğendim :

En azından benim için inceleme sadece iyi kod kalitesini sağlamakla ilgili değil, aynı zamanda bilgiyi yaymak ve anlayışı geliştirmekle ilgili. İlk başta belki bir kişi var, yazar (ve o verilen bir değil), kodu anlamak. İyi bir incelemeden sonra, köşe davaları da dahil olmak üzere, onu tam olarak anlayan en az iki kişi bulunmalıdır.

Kod HER ZAMAN daha iyi olabilir.

Bir kod incelemesindeyseniz ve daha iyi olabilecek bir şey göremiyorsanız veya bir hatayı yakalayabilecek bir birim testini göremiyorsanız, mükemmel olan kod değil, işini yapmayan gözden geçiren kişidir. Gelişmeden bahsetmeyi seçip seçmemeniz kişisel bir seçimdir. Ancak ekibiniz bir kod incelemesi yaptığında neredeyse her zaman birinin daha iyi olabileceğini fark ettiği şeyler olmalı ya da herkes zamanını boşa harcadı.

Bununla birlikte, yorumlar üzerinde hareket edip etmemeniz sizin ekibinize kalmış. Değişiklikleriniz sorunu giderirse veya ekibinizin kabul ettiği herhangi bir değişiklik yapmadan yeterli miktarda değer eklerse, bunları birleştirin ve birisinin daha sonra ele alabilmesi için yorumlarını biriktirerek oturum açın. Eğer takım yaptığınız değişiklikler değerden daha fazla risk veya karmaşıklığa bulur o zaman buna göre sorunları çözmek zorundayız.

Unutmayın, herhangi bir kodun test edilebilecek ve en az bir tane daha yeniden düzenleme kullanabilecek en az bir tane daha ileride bir vakası olduğunu unutmayın. Bu nedenle kod incelemeleri en iyi şekilde, herkes aynı anda aynı koda bakan bir grup olarak yapılır. Böylece, sonunda herkes, gözden geçirilen kodun kabul edilebilir olup olmadığı (olduğu gibi) kabul edilebilir olup olmadığı ve topluluk tabanına birleştirmek için yeterli bir değer kattığı ya da birleştirmek için yeterli bir değer bulunmadan önce bazı şeylerin yapılması gerektiği konusunda fikir birliğine varabilir. .

Bu soruyu sorduğundan beri, aslında "kod incelemeleri" yapmadığınızı, bunun yerine başkalarının belirleyici olmayan bir şekilde yorum yapmaları için bir çekme isteği veya başka bir gönderme mekanizması oluşturduğunuzu varsayıyorum. Öyleyse şimdi bir yönetim sorununa ve yapılanma tanımına giriyorsunuz. Yönetiminizin kararsız olduğunu ve kod incelemelerinin sürecini ve amacını gerçekten anlamadığını ve muhtemelen "yapılan bir tanım" (DOD) olmadığını tahmin ediyorum. Çünkü DOD'unuzu yapmışlarsa bu soruya açıkça cevap verecekti ve buraya gelip sormanız gerekmeyecekti.

Nasıl tamir edersin? Yöneticinizden size bir DOD vermesini isteyin ve her zaman tüm yorumları uygulamak zorunda olup olmadığınızı size söyleyin. Söz konusu kişi müdürünüz ise, cevap açıktır.

Bu soru, savunma programlamanın erdemleri, köşe davalarının tehlikeleri veya fiziki ürünlerdeki hataların felaket riskleri ile ilgili değildir. Aslında bu aslında hiç yazılım mühendisliği ile ilgili bile değil .

Asıl mesele, bir genç pratisyen, bir genç pratisyen tarafından kabul edilemez veya takdir edemediğinde üst düzey bir pratisyen tarafından verilen bir talimatı nasıl ele aldığıdır.

Küçük bir geliştirici olmak için takdir etmeniz gereken iki şey var. Birincisi, bu haklı olmanızın mümkün olduğu ve yanlış olduğu takdirde, olasılıkların dengesinde olduğu anlamına gelir . İş arkadaşınız değerini göremediğiniz bir öneride bulunuyorsa, anlayabileceğiniz kadar deneyimli olmadığınız olasılığını ciddiye almanız gerekir. Bu yazıdan bu anlamda anlamıyorum.

Takdir edilecek ikinci şey, kıdemli partnerinizin daha fazla sorumluluğa sahip olduğu için sözde olmasıdır. Bir çocuk önemli bir şeyi kırarsa, talimatları izlerse başları belaya girmez. Bununla birlikte, eğer bir kıdemli , bunları kırmalarına izin verdiyse - örneğin, kod incelemesinde sorunları gündeme getirmeyerek - haklı olarak çok rahatsız olurlardı.

Nihayetinde, işinizin projelerine liderlik etme konusunda güven duyduğunuz talimatlara uymanız, işinizin gizli bir gerekliliğidir. Genelde tecrübelerine değer vermek için iyi bir neden olduğunda yaşlıları ertelemez misiniz? Anlayamadığın hiçbir talimatı takip etmeyi düşünmüyor musun? Siz ikna olana kadar dünyanın durması gerektiğini düşünüyor musunuz? Bu değerler bir takımda çalışmakla uyumlu değildir.

Son bir nokta. Altı ay önce yazdığınız projeleri tekrar düşünün. Üniversitede yazdığınız projeleri düşünün. Şimdi ne kadar kötü göründüğünü görün - tüm böcekler ve baş aşağı tasarım, kör noktalar ve yanlış yönlendirilmiş soyutlamalar? Ya altı ay sonra bugün yaptığınız işteki aynı kusurları hesaba katacağımı söylesem? Bu, mevcut yaklaşımınızda kaç tane kör nokta olduğunu göstermeye yardımcı oluyor mu? Çünkü tecrübenin yarattığı fark budur.

koduma sürekli olarak, gereğinden fazla iş yapmamı öneren yorumlar yapar.

Öneriler verebilir, ancak neyin gerekli olduğuna karar vermek senin rolün değil. Hangi yönetimi veya (bu durumda gözden geçiren kişinin) karar vermesinin gerekli olduğuna karar vermek sizin işinizdir. Neyin çok fazla veya çok güçlü bir şekilde gerekli olduğuna katılmıyorsanız, muhtemelen kendinizi bir işten bulabilirsiniz. Sonuç olarak, bununla başa çıkmak ve onunla barış içinde olmak profesyonelliğin bir parçası.

Olması muhtemel olmayan karanlık bir olayı ele almamı önerdi.

Burada, böcek olmayanların bile (örneğin, hiç bir zaman başarısızlığa uğramayacak bir şeyin ) hala nasıl çalışılabileceğini gösteren başka büyük cevaplar vardır . (örneğin, ürünün gelecekteki güvenliğinde bina olması durumunda, standartlara uyulması vb.) Büyük bir geliştiricinin rolünün bir parçası, aklınıza gelebilecek her durumda ve gelecekte akla gelebilecek her durumda sağlam olacağından emin olmaktır. Ayrıca, çoğu zaman mevcut koşullar altında yalnızca test edilmiş koşullar altında çalışmaz

Kod gözden geçirmenizin ticari yararlılığını artırmak için kod gözden geçirenlere öneriler (OP olarak böyle bir değişiklik yapmalısınız):

• Yorumlarınızı türe göre işaretleyin. "Kritik" / "Yapmanız Gereken" / "İsteğe Bağlı" / "Önerilen iyileştirmeler" / "olması güzel" / "Ben musing".

  Bu çok CDO / anal / karmaşık görünüyorsa, en azından 2 seviye kullanın: "Gözden geçirmeyi geçmek ve değişikliğinizi birleştirmek için izin verilmelidir" / "Diğerleri".

Kod inceleme önerileriyle ilgili öneriler yapmak için daha az kritik görünen önerileri:

• Tercih sisteminizde açık bir bilet yaratın (ekibiniz umarım kullanıyor mu?), Öneriyi takip edin

• İşleminiz Balık Gözü veya e-posta incelemeleri gibi yorumlara yanıt veriyorsa, kod no.

• Gözden geçirene uzanarak bu öğenin "düzeltilmesi veya birleştirilmemesi / serbest bırakılmaması" türünden olup olmadığını açıkça sorun.

  • Cevabınız "Evet" ise, ancak aynı fikirde değilseniz, proje yönetiminden sorumlu olan kişinin (Başbakan, yöneticiniz vb.) Karar vermesine izin verin - anlaşmazlığı tam ve dürüst bir şekilde sunun. Bu, hanginizin "doğru" olduğu ile ilgili değil, proje için neyin daha iyi olduğu ile ilgili olarak, PM / müdürün işi.

Şimdi, bu bileti başka bir geliştirme talebi olarak kabul edin.

1. Yükseltme işleminden sonra acil olmaya karar verilirse, herhangi bir acil durum talebi olarak kabul edin. Diğer işlerden caydırmak ve bu konuda çalışmak.

2. Aksi halde, önceliğine ve diğer yatırım getirisine göre üzerinde çalışın (bu, diğer cevaplarda açıklandığı gibi iş hattınıza göre farklılık gösterebilir).

Bunu yönetime yükseltmemelisin .

Çoğu şirkette yönetim görevlisi her zaman bu ekstra testi yazmamayı, kod kalitesini geliştirmek için marjinal bir şekilde zaman harcamayı, yeniden yapılanmayı kaybetmemeyi seçecektir.

Çoğu durumda kod kalitesi, geliştirme ekibindeki yazılı olmayan kurallara ve programcıların koyduğu ekstra çabaya bağlıdır.

Bir olan genç geliştirici ve bu sizin ilk kod inceleme . Tavsiyeyi kabul etmeli ve işi yapmalısınız. İş akışını ve ekibinizdeki kuralları yalnızca, bir süre onları ilk önce biliyor ve saygı duyuyorsanız geliştirebilirsiniz, böylece neden orada olduklarını anlayabilirsiniz . Aksi taktirde, kurallara saygı göstermeyen ve ekibin yalnız kurtu olan yeni adam olacaksın.

Takımda yenisin, bir süredir aldığın önerileri takip et, neden orada olduklarını öğren, scrum toplantısında ilk aklına gelen önerileri getirme. Asıl iş öncelikleri bir süre sonra sormadan size açık olacaktır (ve yönetim görevlisinin size yüz yüze söyleyeceği şey olmayabilir).

Liderinizin / yönetiminizin isteğini karşılayan kod yazmanız çok önemlidir. Başka bir ayrıntı sadece "sahip olmak güzel" olurdu. Alanınızda uzmansanız ("küçük bir geliştirici değilseniz:" yazın), o zaman her zaman liderlerinize danışmadan yol boyunca bulduğunuz küçük sorunları ele almaya "hak kazanırsınız".

Bir şeyin yanlış olduğunu düşünüyorsanız ve kendi alanınızda nispeten uzmansanız, şansınız yüksek demektir .

İşte size yararlı olabilecek bazı ifadeler:

• X yapmam istendi, kod yorumcusu Y yapmayı da öneriyor, yapmalı mıyım yoksa daha önemli şeylere mi geçmeliyim?
• Bana Y'yi öneriyorsun, bu yüzden bu davranışı yakalayabilecek en az bir test durumu bulabilir misin? Bu kodun çağrılmayacağına inanıyorum.
• Belki de önce ele geçen davalar için güvenli bir geri dönüş geliştirmemeliyiz? Bu yüzden onları erken yakalar ve hareket halindeyken düzeltiriz, böylece daha önemli şeylere odaklanabiliriz.
• Ben Y uygularken am süre Tamam, bunun için bazı test durumları yüzden o şey halletmek yazmaya kadar nazik olabilir ve son kez ?
• X yapmam istendi ve başka öncelikler olmadığı sürece Y yapabilirim diye düşünüyorum. Bir dahaki sefere neden koduma inceleme yorumu yapmak yerine bir özellik isteği göndermiyorsunuz ? En azından, uygulamadan önce diğer ekip üyelerinden bu özellik hakkında daha fazla fikir duyabiliyoruz (genellikle önemli olan her şey bir özellik olmalı ve birden fazla kişi tarafından ele alınmalı; genellikle kod gözden geçirme kod ve çözüm yaklaşımlarını gözden geçirme konusunda olmalıdır; hata onarımı ve özellikleri).

Gözden geçiren kişinin tutumunun projeye zarar verdiğini ciddi olarak mı düşünüyorsunuz, yoksa çoğu zaman haklı olduğunu mu düşünüyorsunuz (belki de bazen değerlendirme konusunda ufak hatalar yapar ve bunu abartır).

Bana göre, kod incelemesinde yer almayan şeyler yazıyor gibi geliyor, bu kötü bir uygulama çünkü herkesin bir şeyler izlemesini zorlaştırıyor. Ancak başka ne yorum yazdığını bilmiyorum, bu yüzden başka durumlarda hiçbir şey söyleyemem.

Genel olarak aşağıdakilerden her ikisinden de sakınmayı deneyin:

• İstediğiniz şeyi yapmıyorsunuz
• Gözden geçiren kişi aptal hissettiriyorsun

Eğer aslında kodunuzu gözden geçiriyorsa, bunun nedeni yönetimin kendinizden daha fazla güvenmesidir.

Kapsam incelemesi sırasında kapsamla ilgili anlaşmazlık olduğunda:

1. Gerçekte kodun kapsadığı kapsamı belgeleyin. Kimse kötü sürprizlerden hoşlanmaz.
2. Bu kapsamın bir iş kararı olduğunu anlayın. Kapsam, bir özellik üzerinde çalışmaya başladığınızda zaten bilinmelidir, ancak değilse, daha sonra her zaman açıklama isteyebilirsiniz.

Kod incelemesi iş kararlarını veren ise, kapsamı kod incelemesi sırasında bile istediği zaman değiştirebilir, ancak kod incelemesi görevinde yapmaz.

Kenar davanın imkansız olduğunu kanıtlayamazsanız, mümkün olduğunu varsaymalısınız. Mümkünse, sonunda gerçekleşmesi kaçınılmazdır ve daha sonra değil. Son durum testte gerçekleşmediyse, bu test kapsamının eksik olduğu yönünde bir ipucu olabilir.

1. Geri bildirimi kabul et.
2. Kodunuzda herhangi bir değişiklik yapmadan önce, son durum için bir test oluşturmak için elinizden geleni yapın ve bir test hatası alıp alamayacağınıza bakın (sorunun var olduğunu kanıtlayın). Bunun bir test başarısızlık bir tür bir test vakası oluşturun ve almak mümkün değil ise, o zaman olabilir (ben böyle bir sonuç çıkarmak için kararsız olurdu rağmen) kenarı durumda aslında imkansız olduğu sonucuna varmak mümkün.
3. Bir test hatası alabilirsiniz, testi geçmek için uygun kod değişikliğini uygulayın.

Ürünün iyiliği için, muhtemelen kenar kasayı üretip bir arızaya neden olmak isteyebilirsiniz, böylece düzeltmeyi uygulayabilir ve olası bir sorunun önlendiğine güvenebilirsiniz.

Kod incelemelerinin tüm amacı, koda ek olarak göz atmaktır. Hiçbirimiz hatalardan ve gözetimden bağışık değiliz. Bir kod parçasına defalarca bakmak ve yeni bir çift gözün derhal alabileceği açık bir hata farketmemek çok yaygındır.

Dediğiniz gibi, yeni bir algoritma uyguladınız. Yeni algoritmanızın davranışı hakkında selefinin davranışına veya gözlemlerine dayanarak sonuç çıkarmak akıllıca olmaz.

Ne yaptıklarını bilen kod gözden geçirenler var ve eğer bir şeyin değiştirilmesi gerektiğini söylerlerse, o zaman değiştirilmeleri ve bir şeyin test edilmesi gerektiğini söylediklerinde, test edilmeleri gerekiyor.

Başkaları için işe yaramaz bir iş yaratarak kendi varlıklarını haklı göstermesi gereken kod gözden geçirenler var.

Hangisine karar vereceğiniz ve hangisinin ikinci türle başa çıkılacağı hangisi daha çok workplace.stackexchange için bir sorudur.

Eğer scrum kullanıyorsanız, soru şu ki, işinizin yapması gerekeni yapıp yapmadığını (görünüşe göre yapar) ve son derece nadir ve belki de imkansız olan bir olayı, öncelik sırasına göre bırakılacak şekilde ve bunun için öncelikli olarak bırakabilirsiniz. bir sprint içine gittiğinde, gözden geçiren kişi onu almaktan ve 13 saatlik çalışmayı yapmaktan çekinebilir. Eğer X işini yapıyorsanız ve X işini yaptığınız için, Y işinin de yapması gerektiğini fark edersiniz, o zaman Y işi X işinin bir parçası olmaz, bu kendi bağımsız işidir.