Çevik Uygulamalar: Kod İnceleme - İnceleme başarısız mı veya bir sorun mu var?

2 haftalık sürenin sonunda sprint ve bir görevin kod incelemesi var. İncelemede çalışan, okunabilen bir işlev olduğunu keşfettik, ancak oldukça uzun ve birkaç kod kokusu var. Kolay refactor işi.

Aksi halde görev, yapılan tanımlara uyar.

İki seçeneğimiz var.

• Kod incelemesinde başarısız olun, böylece bilet bu sprintte kapanmaz ve biz de moralimizi biraz düşürürüz, çünkü biletten geçemiyoruz.
• Refactor küçük bir çalışmadır ve bir sonraki sprintte (hatta başlamadan önce) küçük, yarım noktalı bir hikaye olarak yapılırdı.

Sorum şu: Bir gözden geçirmenin arkasından bir bilet almaktan, başarısız olmak yerine herhangi bir sorun ya da endişeniz var mı?

Kaynak kodunu bulabildiğim ve okuyabildiğim kaynaklar genellikle% 100 ya da hiçbiri olarak okuyor, ancak bunun genellikle gerçekçi olmadığını görüyorum.

Gözden geçirmenin arkasında bir biletin gözden geçirilmesinden ötürü bir bilet yükseltme konusunda doğabilecek herhangi bir sorun veya düşünceniz var mı?

Doğasında değil. Örneğin, mevcut değişimin uygulanması zaten var olan, ancak şu ana kadar bilinmeyen / belirgin olmayan bir sorunu ortaya çıkarmış olabilir. Biletin başarısız olması, gerçekte tanımlanan görevle ilgisi olmayan bir şey için başarısız olacağınız için haksızlık olur.

derlemede bir işlev keşfediyoruz

Ancak, buradaki fonksiyonun mevcut değişiklik tarafından eklenen bir şey olduğunu tahmin ediyorum. Bu durumda, kod koku testini geçemediğinden bilet başarısız olmalıdır.

Çizgiyi nereye çizersin, çizdiğin yere olmasaydın? Açıkça bu kodun mevcut haliyle kod tabanında kalmak için yeterince temiz olduğunu düşünmüyorsunuz; Öyleyse neden biletin geçmesini düşünürsünüz?

Kod incelemesinde başarısız olun, böylece bilet bu sprintte kapanmaz ve biz de moralimizi biraz düşürürüz, çünkü biletten geçemiyoruz.

Sanırım dolaylı olarak, bu bilete kod üssünün kalitesinden faydalanmak yerine, takım moralini sağlamak için bir geçiş yapmaya çalıştığınızı iddia ediyormuşsunuz gibi geliyor.

Bu durumda, o zaman önceliklerini karıştırdın. Temiz kod standardı basitçe değiştirilmemelidir çünkü takımı daha mutlu eder. Kodların doğruluğu ve temizliği ekibin havasına bağlı değildir.

Refactor küçük bir çalışmadır ve bir sonraki sprintte (hatta başlamadan önce) küçük, yarım noktalı bir hikaye olarak yapılırdı.

Orijinal biletin uygulanması kodun kokusuna neden olmuşsa, orijinal bilette ele alınmalıdır. Yeni bir bilet yaratıyor olmalısınız, ancak kod kokusu doğrudan orijinal bilete atfedilemezse (örneğin, "deveyi geri kıran bir saman" senaryosu).

Kaynak kodunu bulabildiğim ve okuyabildiğim kaynaklar genellikle% 100 ya da hiçbiri olarak okuyor, ancak bunun genellikle gerçekçi olmadığını görüyorum.

Geçti / kaldı doğal olarak bir ikili durumdur , bu doğal olarak hepsi ya da hiç değildir.

Burada atıfta bulunduğunuz şey bence, kod incelemelerini mükemmel kod gerektiriyor veya başka şekilde başarısız olarak yorumluyorsunuzdur , ve durum böyle değil.

Kod kusursuz olmamalıdır, ekibinizin / şirketinizin kullandığı makul temizlik standardına uymalıdır. Bu standarda bağlılık ikili bir seçimdir: yapışır (geçer) veya geçmez (başarısız).

Konuyla ilgili açıklamanıza dayanarak, bunun beklenen kod standardına uyduğunu düşünmediğiniz ve bu nedenle de takım moralleri gibi açık nedenlerden ötürü geçilmemesi gerektiği açıktır.

Aksi halde görev, yapılan tanımlara uyar.

"İşi halleder" kod kalitesi için en iyi kriter olsaydı, o zaman başlamak için temiz kod ve iyi uygulamalar ilkesini icat etmek zorunda kalmazdık - derleyici ve birim testi zaten otomatik inceleme sürecimiz olurdu ve kod incelemelerine veya stil argümanlarına ihtiyacınız olmaz.

2 haftalık bir sprint sonunda ve bir görevi bir kod incelemesi vardır [...] Kolay refactor iş.

Neden bu sprint sonunda açılır? Kod incelemesinin , kodun yapıldığını (veya daha önce) düşündüğünüz an gerçekleşmesi gerekir . Tamamladığınız her hikaye ile yapılan tanımınızı kontrol etmelisiniz.

Demo / sprint incelemenizden çok kısa bir süre önce kendinize "küçük" bir görevle uyulamayacağınızı anlayan hikayeler bulursanız, işinizi tahmin ederken daha iyi olmanız gerekir. Evet, bu hikaye bitmedi. Bir kod incelemesi nedeniyle değil, ancak kod incelemesinden değişiklikler eklemeyi planlamadığınız için. Bu, "test etme" nin sıfır zaman alacağını tahmin etmeye benziyor, çünkü "doğru programladıysanız, işe yarayacak, değil mi?" Çalışma şekli bu değil. Test, hataları bulur ve kod incelemesi değişecek şeyleri bulur. Olmazsa, büyük bir zaman kaybı olur.

Özetlemek gerekirse: evet, DoD ikilidir. Pass veya Fail. Bir kod incelemesi ikili değildir, devam eden bir görev gibi olmalıdır. Başarısız olamazsın . Bu bir süreç ve sonunda bitti. Ancak, doğru şekilde plan yapmazsanız, zaman içerisinde bu "bitmiş" aşamaya gelemezsiniz ve sprint sonunda "bitmemiş" bölgeye sıkışırsınız. Bu moral için iyi değil, ama bunu planlamada hesaba katmanız gerekir.

Basit: Değişikliği gözden geçirirsiniz . Aksi takdirde programın durumunu incelemezsiniz. 3.000 satır işlevinde bir hatayı düzeltirsem, değişikliklerimin hatayı düzelttiğini kontrol edersiniz, o kadar. Değişikliğim hatayı düzeltirse, değişikliği kabul edersiniz.

Eğer işlevin çok uzun olduğunu düşünüyorsanız, o zaman değişikliğim kabul edildikten sonra işlevi kısaltmak ya da bölmek için bir değişiklik isteğinde bulunursunuz ve değişiklik isteğimin önemine göre öncelik verilebilir. Eğer takımın yapacak daha önemli işleri olduğuna karar verilirse, daha sonra ele alınır.

Bir kod incelemesi sırasında geliştirme öncelikleri hakkında karar vermeniz ve saçmalığımın bu nedenle reddedilmesi gelişim önceliklerini belirleme girişimi olacaktır.

Özet olarak, bir kod değişikliğini kabul etmek ve değişikliği gözden geçirirken gördüklerinize göre hemen bir bilet yükseltmek kabul edilebilir. Bazı durumlarda, değişimin kendisi de sorunlara neden olmuşsa, bunu bile yapacaksınız: Değişiklikleri şimdi yapmak, sorunları düzeltmekten daha önemliyse . Örneğin, başkaları engellenmişse, değişikliği bekledikten sonra kod geliştirilebilirken engellemesini kaldırmak istiyorsunuz.

Kod incelemesinde başarısız olun, böylece bilet bu sprintte kapanmaz ve biz de moralimizi biraz düşürürüz, çünkü biletten geçemiyoruz.

Bu problem gibi görünüyor.
Teoride, ne yapman gerektiğini biliyorsun, ama son tarihe yakın, yani yapman gereken şeyi yapmak istemiyorsun.

Cevap basit: Eğer sprint ilk gününde kod inceleme için aynı kodu alırsanız ne yaparsanız yapın. Eğer kabul edilebilir olsaydı şimdi yapmalıydı. Olmazsa, şimdi olmaz.

Sürecin büyük bir kısmı ne karar vermektir yapılan araçlar ve Silahların çekildiği. Ayrıca, testin çalışmanın işlevsel olarak tamamlanmasını sağlamak için akran değerlendirmelerinizin zamanında yapılmaması ve zamanında yapılmaması anlamına gelir.

Kod gözden geçirme sorunlarına gelince, bununla başa çıkmanın birkaç yolu vardır ve doğru seçim birkaç faktöre bağlıdır.

• Sadece kodu kendin temizleyebilir ve ne yaptığını öğren. Bazı mentorluk fırsatları sunar, ancak bu birkaç dakika içinde yapılabilecek oldukça basit şeyler olmalıdır.
• Neyin yanlış olduğuna dair yorumlarla geri atabilirsiniz . Hata işlemesi kötü yapılırsa veya geliştirici aynı hataları tekrarlamaya devam ederse, bu garanti edilebilir.
• Şunları yapabilirsiniz Bir bilet oluşturmak ve teknik borçlanmak. Bilet daha sonra ödediğinizden emin olmak için orada. Bir zaman sıkıntısı çekiyor olabilirsiniz ve değişiklikleri gözden geçirme sürecinde, doğrudan değişiklikle ilgili olmayan daha büyük bir sorun görürsünüz.

Alt satırda, işiniz bittiğinde, onunla birlikte yapmanız gerekir. Geliştiricinin çalıştığından daha büyük sorunlar varsa, bayrağı kaldırın ve devam edin. Ancak, sprint bitmeden saatlerce sürecek bir durumda olmamalısınız ve şimdi tam da akran değerlendirmesini alıyorsunuz. Bu, kaynaklarınızı fazlaca kullanmak veya arkadaş incelemelerine ertelemek gibi kokuyor. (bir işlem kokusu).

Kod inceleme sorunlarının yaygınlaştırılmasıyla ilgili doğal bir sorun yoktur, ancak bir ekip olarak üzerinde anlaşmanız gereken ana konular gibi görünmektedir:

1. Kod incelemenizin amacı nedir?
2. Kod incelemesinin sonuçları, bir iş öğesi için Yapılan İşlem tanımı ile nasıl ilişkilidir?
3. Kod incelemesi bir yolluk testi olarak uygulanırsa, hangi sorunların 'engelleyici' olduğu kabul edilir?

Tüm bunlar takımın Bitti tanımı olarak kabul ettiği şeye bağlı. Kod incelemesini Sıfır Sorunlar ile geçmek bir iş öğesi için yapılan tanım ise, bu gereksinimi karşılamayan bir öğeyi kapatamazsınız.

Ünite testi sırasında ünite testi başarısız olmuş gibi aynıdır. Birim testlerini geçmek bir Bitirme işlemi için gerekliyse, hatayı düzeltirsiniz, ünite testini dikkate almazsınız.

Ekip, incelemeleri Yapılan İşlem tanımı olarak kodlamayı kabul etmediyse, kod incelemeleriniz iş öğesinin giriş kabul testi değildir. İhtiyaç duyulabilecek ek işleri aramak için, birikim sürecinizin bir parçası olan bir takım etkinliğidir. Bu durumda, keşfettiğiniz sorunlar orijinal iş öğesinin gereklilikleriyle ilgisi yoktur ve ekibin önceliklendireceği yeni iş öğeleridir.

Örneğin, bir takımın bazı değişken isimlerindeki sabitleme yazım hatalarını belirsizleştirmesi tamamen kabul edilebilir, çünkü ekip "myObkect" değişken adını gerçekten görmekten nefret etse de, teslim edilen işletme işlevselliğini etkilemez.

Burada daha yüksek oy alan cevaplar çok iyi; bu bir yeniden ateşleme açısını ele alır.

Çoğu durumda, yeniden yapılanma sırasındaki işlerin çoğu mevcut kodu anlamaktır; ondan sonra değiştirmek genellikle iki nedenden biri nedeniyle işin daha küçük kısmıdır:

1. Sadece kodu daha net ve / veya özlü hale getiriyorsa, gerekli değişiklikler açıktır. Genelde, daha temiz görünen ve gerçekten işe yarayıp yaramadıklarını ya da daha karmaşık kodda biraz incelik kaçırdıklarını görünce değişiklikleri deneyerek, kodu anladığınızı anladınız.

2. Yeni bir özellik oluşturmayı kolaylaştırmak için ihtiyaç duyduğunuz belirli bir tasarım veya yapıya zaten sahipsin. Bu durumda, bu tasarımın geliştirilmesine yönelik çalışma, bunun için ihtiyacı yaratan hikayenin bir parçasıydı; bu tasarıma ulaşmak için refactoring yapmak zorunda olduğunuzdan bağımsızdır.

Mevcut kodu öğrenme ve anlama, kalıcı olmayan bir fayda için adil bir iş miktarıdır (bir ay sonra birileri o zaman boyunca okumaya ya da üzerinde çalışmaya devam etmiyorsa, kod hakkında fazla şey unutmuş olabilir). Bu, size sorun yaratan ya da yakın gelecekte değişmeyi planladığınız kod alanları haricinde bir anlam ifade etmiyor. Buna karşılık, bu yeniden yapılanmanın ana işi olduğundan, şu anda size sorun çıkarmadan ya da yakın bir gelecekte değiştirmeyi planlıyorsanız, kodda yeniden yapılanma yapmamalısınız.

Ancak bunun bir istisnası var: eğer birisi şu anda zamanla kaybolacak kodu iyi anlıyorsa, bu anlaşmayı daha sonra açık ve anlaşılır hale getirmek için bu anlayışı kullanmak iyi bir yatırım olabilir. Hikaye geliştirmeyi yeni bitirmiş birinin durumu bu.

Refactor küçük bir çalışmadır ve bir sonraki sprintte (hatta başlamadan önce) küçük, yarım noktalı bir hikaye olarak yapılırdı.

Bu durumda, yeniden yapılanma için ayrı bir hikaye yapmayı düşündüğünüz birkaç cephede bir uyarı işaretidir:

1. Yeniden düzenlemeyi kodlamanın bir parçası olarak değil, ayrı bir işlem olarak görüyorsunuz, bu da baskı altında kalmayı olası kılıyor.

2. Bir dahaki sefere birisinin onunla çalışması gerektiğinde, hikayelerin daha uzun sürmesini sağlamak için daha fazla iş olacak kod geliştiriyorsunuz.

3. Fazla faydalanmadığınız şeyleri yeniden düzenleyerek zaman ve enerji harcıyor olabilirsiniz. (Bir değişiklik daha sonra gerçekleşirse, birisi yine de kodu tekrar anlamak zorunda kalır; yine de; yeniden düzenleme işiyle daha verimli bir şekilde birleştirilir. Bir değişiklik daha sonra gerçekleşmezse, yeniden düzenleme hiçbir işe yaramadı. Amaç, belki de estetik olan dışında.)

Bu nedenle, buradaki cevap, işleminizdeki bir şeyin başarısız olduğunu açıkça belirtememesi için öğenin başarısız olması (bu durumda, geliştirici veya ekibin incelemeden çıkan değişiklikleri gözden geçirmek ve uygulamak için zaman ayırmaması) ve geliştiricinin derhal çalışmaya devam etmesini sağlamaktır. öğe üzerinde.

Bir sonraki yineleme için tahminde bulunacağınız zaman , mevcut hikayeyi , gözden geçirmeyi geçip bir sonraki yinelemenize eklemek, ancak bir önceki yinelemeden tahminde tutmak için ne kadar iş kaldığı görünüyorsa tekrar tahmin edin. Hikaye bir sonraki yinelemenin sonunda tamamlandığında, tarihsel toplam iş miktarını birinci ve ikinci tahminlerin toplamına ayarlayın, böylece ne kadar tahmini işin gerçekten yapıldığını bilirsiniz. Bu, sürecinizin şu anki haliyle gelecekte benzer hikayelerin daha doğru tahminlerini üretmeye yardımcı olacaktır. (Yani, görünüşte eksik tahmininizin bir daha olmayacağını varsaymayın; daha az çalışarak benzer hikayeleri başarıyla tamamlayana kadar bunun tekrar olacağını varsayalım.)

Bir kod incelemesinin “başarısız” olduğu fikrine cevap ve yorumlardaki cevap eksikliğinden şaşırdım, çünkü bu şahsen tanıdığım bir kavram değil. Ayrıca bu terminolojiyi kullanan o kavramla veya ekibimdeki herhangi biriyle rahat edemem.

Sorunuz açıkça "çevik uygulamalar" anlamına geliyor, bu yüzden çevik manifestoyu tekrar gözden geçirelim (benimkine önem ver):

Bunu yaparak ve başkalarına da yardımcı olarak yazılım geliştirmenin daha iyi yollarını açığa çıkarıyoruz. Bu çalışma sayesinde değere ulaştık:

• Bireyler ve süreçler ve araçlar üzerindeki etkileşimler
• Kapsamlı dokümantasyon üzerinde çalışan yazılım
• Sözleşme müzakere konusunda müşteri işbirliği
• Bir planı takip etmeyi değiştirmeye cevap vermek

Yani, sağdaki öğelerde değer varken, soldaki öğelere daha çok değer veriyoruz.

Takımınla konuş. Söz konusu kodu tartışın. Maliyetleri ve faydaları değerlendirin ve kararlaştırıcı bir uzmanlar grubu olarak bu kodu şimdi mi yoksa sonra mı değiştireceğinizi kararlaştırın.

Ortak çalışmaya başla. Kod incelemelerinde başarısız olun.

İncelemede çalışan, okunabilen, ancak oldukça uzun bir kod kokusu olan bir işlev keşfettik ...

Gözden geçirmenin tersine, biletin gözden geçirilmesinden ötürü bir bilet yükseltme konusunda doğabilecek herhangi bir sorun veya düşünceniz var mı?

Herhangi bir sorun yok (benim görüşüme göre). Kodun bilette belirtilen kabul kriterlerini karşıladığını kabul ediyorum (yani çalışıyor). Uzunluğu ve herhangi bir kodun kokusunu gidermek için bir backlog öğesi oluşturun ve diğer biletler gibi önceliklendirin. Eğer gerçekten küçükse, o zaman bir sonraki sprint için sadece yüksek öncelik verin.

Elimizdeki sözlerden biri "Ertelenen mükemmelliğe göre ilerici iyileşmeyi seç".

Çok akıcı bir sürecimiz var ve oldukça iyi bir sayıda 'kavram kanıtı' özelliği (sprint başına 1 veya 2) geliştirip test ettik, ancak bunu hiçbir zaman iç paydaş incelemesini geçmeden yapamayacağız (hmm, bunu yapabilir miyiz) ?), alfa veya beta ... bazıları hayatta kalır, bazıları kalmaz.

Mevcut projede, belirli bir özelliği ne kadar geliştirdiğimizi, paydaşların eline aldığımızı ve bir ya da iki yıl sonra, ürün yönü değiştiği ya da gereklilikleri neden olduğu için tamamen kaldırdığımızın izini kaybettim. Özelliğin nasıl uygulanması gerektiğine dair tam bir tekrar. Silinen bir özellik için kalan ya da yeni gereksinimlere uymayan tüm 'ayrıntılandırma' görevleri, biriktirme işleminin bir parçası olarak silinir.

Bence bu soruna bakmanın iki yolu var:

1. Akademik yolu
2. Gerçek dünya yolu

Akademik olarak konuşursak, çoğu kod inceleme süreci, kod kalitesi standardı karşılanmadığında bir PBI'nın (ürün biriktirme kalemi) konuşlandırılmasında başarısız olur.

Bununla birlikte, gerçek dünyadaki hiç kimse T'yi (birçok nedenden ötürü) olduğu için çevik olarak takip etmemektedir, farklı endüstrilerin farklı gereksinimleri vardır. Bu nedenle kodu şimdi düzeltmek veya teknik borç almak (büyük olasılıkla yeni bir PBI oluşturacaksınız) duruma göre karar verilmelidir. Sprint veya salınımdan ödün vermesi veya makul olmayan bir risk getirmesi durumunda, iş paydaşları karara katılmalıdır.

Hiçbiri . Kod incelemesini geçemezse görev yapılmaz. Ancak kişisel görüşlere göre kod incelemelerinde başarısız olamazsınız. Kod geçer; Bir sonraki göreve geç.

Kolay bir arama olmalı ve kod incelemeleri için yeterince açık yazılı kurallara sahip olmadığınıza işaret etmiyor olması gerçeği.

1. "İşlev oldukça uzun". Yazma: İşlevler, X satırından daha kısa olmalıdır (işlev uzunluğu ile ilgili kuralların iyi bir şey olduğunu düşünmüyorum ).

2. Msgstr "Bazı kod kokuları var". Yazma: genel işlevler işlevsellik ve performans için birim testlerine sahip olmalı, hem CPU hem de bellek kullanımı x ve y limitleri altında olmalıdır.

Bir kod incelemesini geçme kurallarını belirleyemiyorsanız, temelde 'sevmediğiniz kod' olanı alırsınız.

'Sevmediğin bir kod' bırakamaz mısın? Hayır derdim. Doğal olarak, kod dışı özelliklere dayanarak geçmeye / başarısız olmaya başlayacaksınız: Kişiyi beğendiniz mi? Davaları için güçlü bir şekilde tartışıyorlar mı yoksa söyleneni yapıyorlar mı? Seni incelerken kodunu geçiyorlar mı?

Ayrıca, tahmin sürecine tahmin edilemez bir adım eklersiniz. Nasıl programlanması gerektiğini düşündüğümüzü temel alan bir görev tahmin ediyorum, ancak en sonunda kodlama stilini değiştirmem gerekiyor.

Bu ne kadar sürecek? Aynı gözden geçiren müteakip kod incelemesini yapacak ve ilk gözden geçirene katılacak mı yoksa ek değişiklikler mi yapacak? Değişikliğe katılmazsam ve ikinci bir görüş ararken ya da tartışırken bunu yapmaktan vazgeçersem ne olur?

Görevlerin hızlı bir şekilde yapılmasını istiyorsanız, bunları mümkün olduğunca spesifik hale getirmeniz gerekir. Belirsiz bir kalite kapısı eklemek, verimliliğinize yardımcı olmaz.

Re: Kuralları yazmak imkansız!

Gerçekten o kadar zor değil. Gerçekten "Neyi kastettiğimi 'iyi' kodla ifade edemiyorum" demek istedin . Bunu bir kez anladıktan sonra, birisinin çalışmalarının sıfırdan olmadığını söylemeye başlarsanız, bunun neden olduğunu söyleyemezseniz, bunun açıkça bir İK sorunu olduğunu görebilirsiniz.

Yapabileceğiniz kuralları yazın ve kodu 'iyi' yapan şeylerle ilgili bira üzerine konuşun.