Büyük kod incelemesinin ekibimde saklandığından şüpheleniyorum. Çok fazla kod incelemesi yorum yapılmadan birleştirildi.

Bana tek bir yorum yapmadan kod incelemesi diye bir şey yokmuş gibi görünüyor.

Bir ekip lideri olarak ekibimin uygun bir kod inceleme süreci yaptığını nasıl izleyebilirim ve sürecin faydalarını maksimize etmelerine nasıl yardımcı olabilirim?

Güncelleştirme

İnsanların herhangi bir güncelleme hakkında bilmek isteyebileceğini düşündüm. Burada verilen birçok öneri denedim. çoğu zaten kullanılıyordu. Bazıları biraz yardımcı oldu. Ancak, sorun devam etti - bazı insanlar ben bakmadığımda sürekli olarak kötü kodlar aldılar.

Kod inceleme izlemenin, ekibime kodlarını daha iyi hale getirmeleri için araç gereçlerimi vermek kadar yararlı olmadığını gördüm.

Kopya kopyalarını tespit etmek için "jscpd" adlı bir kütüphane ekledim. Kopya kopyalarına yapılamadı. Bu hemen bir sorunu ortadan kaldırdı.

daha sonra kodeklimat deneyeceğiz.

Ben de yarım gün sprint bir kez eski kod incelemeleri bir manuel inceleme yapıyorum. Bunları todosorunlara / biletlere dönüştürüyorum - insanların yazdıklarını öğrendiğim gibi, ancak daha sonra hiçbir zaman ele alınmıyorlar. Ayrıca uygun olduğunda kodu incelemek için tüm ekiplerle toplantılar yapıyorum.

genel olarak doğru yöne hareket ediyormuş gibi hissediyoruz.

Diğer cevaplayıcılarımdan farklı bir teklif sunacağım. Haklılar - işlerin nasıl yürüdüğünü görmek istiyorsanız dahil olun. Daha fazla izlenebilirlik istiyorsanız, bunun için araçlar var.

Ancak tecrübelerime dayanarak başka bir şey olduğundan şüpheleniyorum.

Ekibinizin çoğu komisyon için sürecin bozulduğunu / aptalca / etkisiz kaldığını hissedebileceğini düşündünüz mü? Unutmayın, süreç uyulması gereken kuralları değil, neyin iyi sonuç verdiğini belgelemektedir . Ve takımın lideri olarak, onların en iyi olmalarına yardımcı olmak için oradasınız, kuralları zorlamıyorsunuz.

Yani retrospektiflerinizde (çevikse) veya bire bir (eğer menajer iseniz) veya rastgele doğaçlama koridor toplantılarında (çevik olmayan bir takım liderliği yapıyorsanız ve onlardan birini yapan başka bir menajer varsa), gündeme getirin . İnsanların kod inceleme süreci hakkında ne düşündüklerini sorun. Nasıl çalışıyor Nasıl değil? Diyelim ki takıma elinden geldiğince faydası olmaz. Dinlediğinden emin ol .

Bu toplantılarda kod incelemeleri için biraz savunuculuk yapabilirsiniz, ancak geri bildirimleri dinlemek daha iyidir. Büyük olasılıkla, ekibinizin "uygun" sürecin ayarlanması gerektiğini düşündüğünü veya (zaman baskısı, hakemlerin eksikliği, Bob sadece kodunu kabul eder, bu yüzden neden yapamayız) sözünü edersiniz. .

Bir takımı kırık bir işlemin üstüne zorlamak, işlemi daha iyi yapmaz.

Tek satırlık cevaplar göndermekten hoşlanmıyorum, ancak bu uygun görünüyor:

Sürece katılın.

ReviewBoard veya Redmine'nin kod görüntüleme eklentisi gibi bir araç edinin . Daha sonra her inceleme başkası tarafından kapatılması veya yorumlanması gereken bir görev olarak yaratılır (tıpkı bir böcek bileti gibi). Ardından, inceleme biletini kimin yarattığını ve kimin kapattığını izlenebilirlik elde edersiniz. İnceleme biletlerini kaynak kodlu check-in'ler ile bağlayabilirsiniz, yani bir revizyondan bilet yaratın.

Birkaç şey (dürüst olmak gerekirse, bunların çoğu cevaplar arasındadır, ancak ben onları tek bir yere koymak istedim)

• Bir kod incelemesinin yapıldığından emin olmak için süreci ve kuralları uygulayabilirsiniz, ancak kod incelemesinin aslında kutu işaretleme alıştırmasından daha fazlası olması için bunları koymak imkansızdır. Nihayetinde ekip, yararlı bir şekilde yaklaşacaksa sürecin faydasını görmelidir.

• Örnek olarak kurşun. Yorumlara katılın. Bir geliştirici olarak, eğer menajerim (şu anda geliştirici olmayan) benim bilmediğim şeyleri görürse kendimi kötü hissediyorum. İncelemede yakalanması gereken hususları vurgulayın (suçlayıcı olmayan bir şekilde). Bir üretim sorunu meydana gelirse, KG sırasında sorunlar ortaya çıkarsa (ayrı bir KG işleminiz varsa) kod incelemesinde nerede yakalandıklarını vurgulayın. Nasıl ekibi ile tartışın biz vardır yakalanmış olduğu gibi gelecekte sorun sağlayabilirsiniz

• Takımla sürecin ne yapmasını istediklerini tartışın. Herhangi bir nokta göremiyorlarsa (başlangıçta olduğu gibi) üretim konularını ve gerekli ekleri faydasının kanıtı olarak kullanın

• Sonarqube gibi otomatik kod denetleme yazılımı kullanın, böylece kod incelemeleri anlaşılmaz kod, mantık hataları, dokümantasyon eksikliği vb. Otomatik olarak algılanamayan sorunlara odaklanabilir.

Ekibin ne istediğini, geliştiricilerle tartıştığınız ve karar verdiğiniz kod incelemelerinde belgeleyebilirsiniz. Kod incelemelerinin bir parçası olarak düşünebileceğiniz bazı şeyler şunlardır:

• Kodun yapılması gerekeni yaptığını, yani gereklilikleri karşıladığını kontrol edin.

• Geliştiricilerin tutarlı bir stile kodlamalarını sağlamak için kod stili

• Optimizasyon, örneğin fonksiyon çağrısı sayısı

• Mimarlık ve yeniden kullanılabilirlik

• Özel durum işleme ve günlüğe kaydetme

• Teknik borç: Kod, geliştiricinin üzerinde çalışmaya başladığından daha iyi bir durumda

• Kodu inceleyin ve oluşturun (bunu yararlı buluyorum ancak ekibimdeki diğer aygıtlar bunu test uzmanlarına bırakmayı tercih ediyor)

• Otomatik bir araç kullanarak ( SonarQube kullandım ). Kodda iyileştirmeler yapmak için bunu test sürecinize entegre etmenin faydalı olduğunu biliyorum, örneğin test kapsamını arttırmak

Yukarıdaki adımların bazıları otomatik bir araç tarafından ele alınabilir, ancak kod incelemelerini veya yapılanları geliştirmeye çalışırken muhtemelen hem aracı hem de göz küresi incelemesini kullanmaya değer. Bununla birlikte, teknik borcu önlemede en önemli adımlar (mimari ve yeniden kullanılabilirlik) tamamen otomatikleştirilemez.

Ekibiniz bunu uygulamakta tutarsızsa, yalnızca kod incelemeleri yapan geliştiricilerin birleştirme haklarına sahip olmalarına izin vermeyi deneyebilirsiniz. Örneğin, sadece takımdaki lider dev ile başlamak isteyebilirsiniz. Bu yaklaşımın takası, bu geliştiricilerin geliştirme sürecinde bir tıkanıklık haline gelebilecekleri, bu yüzden siz ve ekibin bunu isteyip istemediğinize karar vermesi gerekiyor. Şahsen bu takası kabul ederdim ve kod incelemeleri yoluyla takımın geri kalanı arasındaki disiplini arttırır ve ardından hazır olduğunuzda birleştirme haklarına sahip geliştiricilerin sayısını artırabilirsiniz.

Son olarak, değerlendirmeleri incelemeye değer. Dolayısıyla, haftada bir kez geliştiricilerle bir araya gelin ve incelemeleri ve bunları iyileştirme yollarını yapıcı bir şekilde tartışın.

Size ekibimin kod incelemesini iş akışına nasıl hızlı bir şekilde entegre ettiğini anlatacağım.

İlk önce, sana bir soru sorayım. Bir sürüm kontrol sistemi kullanıyor musunuz (örn. Mercurial, Git)?

Cevabınız evet ise, devam edin.

1. Herkesin bir şeyi (hatta küçük düzeltmeleri bile) doğrudan ana dalına (ana hat) itmesini yasaklayın *
2. ayrı dallarda yeni özellikler (veya düzeltmeler) geliştirmek
3. geliştiriciler dalın ustaya entegre olmaya hazır olduğuna inandığında, "çekme isteği" oluşturacaklar
4. herkesin kendi çekme talebini birleştirmesini yasakla *
5. Başka bir geliştiricinin çekme isteğini değerlendirmesini ve yeni kodu incelemesini isteme
6. Kod incelemeyi geçerse, iyi, çekme isteği birleştirilebilir, aksi takdirde düzeltmeler uygulanabilir
7. Kod yeterince olgunlaşana kadar 6. adımı tekrarlayın (yeniden başlamadan yapılabilir) **
8. bittiğinde, tüm yeni kodunuz (en azından özet olarak) adı olan biri tarafından incelenir

Artık iş akışınızda kod incelemesinin yapıldığı kesin bir noktaya sahipsiniz.

Orada hareket.

* sunucu tarafı kancalarla otomatik olarak zorlanabilir

** Bu prosedür tamamen (diğerleri arasında) GitHub'dan tarafından desteklenen ve kolay kullanımı ile oldukça mesafesindedir, bunu kontrol

Bir şablon oluşturup ekip üyelerinizden bir kod incelemesi yaptıklarında bunu güncellemelerini istemeniz gerektiğini düşünüyorum. Ancak o zaman bile, başlangıçta inceleme sürecine katılmalısınız.