Kod İncelemeleri gerçekten gerçek Agile'de çalışıyor mu?


13

Bu yüzden adında 3 harf olanlardan biri olan büyük bir corp için çalışmaya başladım ve Agile olmaya çalışıyorlar, ancak Agile olduğunu hissetmediğim tonlarca süreç var.

Beni en çok yaralanan biri kod incelemeleridir. Son işim, gördüğüm, üzerinde bulunduğum ve / veya duyduğum en Agile geliştirme ekibi.

Her neyse, benim argümanım, Kod İncelemelerinin, UX / UI'nin aşırı / yoğun olduğu yinelemeli veya Çevik gelişimde zaman kaybı olduğu (Apple / Steve Jobs mükemmelliğini düşünün). Belki burada biri beni kovmadan önce anlamaya yardımcı olabilir?

İşte benim gelişim sürecim ve son girişimimdeki süreç ... çok Çevik.

Geliştirme görevini / yapılacakları sıralamak için erken özellikli işleri yapıyoruz. Geri bildirim almak için birkaç sürümü alay eder ve kullanıcılara, ekibe ve pazarlamaya sunarız. Daha sonra yukarıdaki aynı paydaşlardan bir tur almak için başka bir mockup yinelemesi yapıyoruz. Sonra işi bölüyoruz ve başlıyoruz. Karşılaşacağımız kilometre taşları ve tarihlerimiz var, ancak takılmaya devam ediyoruz. Bunların hiçbiri sırasında kod incelememiz yok. Gelişim haftalarımız boyunca birkaç kez, hala özelliklerin / fonksiyonların / UX / UI'nin hala uygun ve hedefte olup olmadığını kabul etmek için paydaşlarla tekrar oturumlar düzenliyoruz.

8 haftalık iterasyon döngüsünün sonuna yaklaştığımızda KG test etmeye başlar, daha sonra alfa kullanıcılarına ve son olarak da beta kullanıcılarına gider. Ancak alfa ve beta geliştiricileri, UX'i iyileştirmek için kullanıcı arayüzünde günlük veya saatte tekrarlanan değişiklikler yapan yeni özelliklerin ve eski özelliklerin üzerinden geçiyor. Bu nedenle, bu sürüm geliştirilmekte olan bir özellik, iyileştirmek ve mükemmelleştirmek veya birkaç küçük özellik eklemek için son dört haftada 3 kez daha değişebilir (örneğin, bileşeni biraz daha ince veya daha akıllı hale getirin). Bazen değişiklikler yüzeysel olabilir, yani hiçbir CRUD işlemi değiştirilmez veya değiştirilmez, ancak tüm kullanıcı arayüzü yalnızca değişir.

Öyleyse, bu tür bir geliştirme süreci olan aşırı Çevik, incelemeleri kodlamak zaman kaybı olmaz mı? Başka bir geliştirici veya iki kodumu gözden geçirmiş olsaydım, ancak daha sonra bu kod kapıdan çıkmadan önce 3 kez daha değişirse, tüm UI / UX geliştirmeleri nedeniyle, ilk 3 kez gözden geçirmedik mi? kod / bileşen / kullanıcı arabirimi hurdaya çıkarıldı mı?

Bu süreçle ilgili pek çok kalite sorunumuz olmadı ve evet, bir geliştirici tüm bilgileri kapıdan çıkardıysa, ancak her zaman onu almak ve devralmak için akıllı geliştiriciler bulduk.

Ve evet, çok fazla testçimiz var, çünkü işleri 3 veya 4 kez tekrar test etmek zorunda kalabilirler. Ayrıca lütfen tüm UI / UX değişikliklerinin nedenini soran takılmayın ... işlerin nasıl yapıldığını ... o zaman uygulama neden UI / UX için tonlarca ödül kazanır ve kullanıcılar Uygulamanın. Düşünce süreci, bir şeyde% 2'lik bir iyileşme bile yapabilirsem, çünkü fazladan bir saatim var, sonra yap. Kullanıcılar daha mutlu olacak, bu da daha fazla $ veya kullanıcı anlamına gelecek. Ve evet, kullanıcılarımız sürekli değişen uygulama ile Tamam, çünkü bu onun ilk günden beri nasıl yapıldığı için kötü ya da olumsuz görmüyorlar.

Umarım bu yazı görkemli değildir, ancak Kod İncelemelerinin nasıl boşa gitmediğini göremiyorum. İncelenen koddaki tüm kodumuzun% 2'sinde hatalar olabilir. Her sürümde kod incelemesi yoluyla 3 hata bulabiliriz. Yani 3 ila 5 hata bulmak için sürüm başına geliştirici başına 40 saatlik kod incelemesi (4 x 40 = 160 saat) olur? Şanslar% 50'dir ve bu 3 ila 5 hata zaten KG tarafından alınırdı. Geliştirici başına 40 saatini yeni bir özellik ekleyerek veya mevcut olanları iyileştirerek geçirmek daha iyi olmaz mıydı?


@DeadMG: Kullanıcı Deneyimi
Steven A. Lowe

4
@ user25702: tarif ettiğiniz işlem Çevik gibi değil, RUP / spiral gibi geliyor. Özellikle "Geliştirme haftalarımız boyunca birkaç kez, hala özelliklerin / fonksiyonların / UX / UI'nin hala uygun ve hedefte olup olmadığını kabul etmek için paydaşlarla tekrar oturumlar düzenliyoruz." anti-çeviktir; RUP / spiral yaklaşımlarıyla ilişkili hareketli hedef problemlerinden kaçınmak için bir yineleme sırasında özellikler dondurulur. Nominal sorunuza gelince, burada kod incelemelerinde çok fazla değer görmüyorum ve sadece hataların QA tarafından bulunacağından eminseniz.
Steven A. Lowe

1
8 haftalık yinelemeler çevik değildir ve kesinlikle "aşırı çevik" değildir.
Martin Wickman

Bazı PM'ler yinelemelerin başlangıçta birkaç kısa yinelememiz ve ortada birkaç uzun yinelememiz olduğu ve sonunda gerektiği kadar kısa yinelemelerin olduğu anlamına gelir. Sorun, bunun yazılım geliştirme savaş ritmi ve hataları erken yakalama yeteneği ile uğraşmasıdır. 8 haftalık yineleme bu orta yinelemelerden biri olacaktır. Bunun çevik olmadığını kabul ediyorum.
Berin Loritsch

Kod incelemelerini tartışmak istiyorsanız, bazı istatistikleri almanızı öneririz. Kod incelemeleri için geçen süreyi (toplam adam saatinde), içinde bulunan hataların / sorunların sayısını ve sorunun ciddiyetini belgeleyin. Ekibim, her biri doğada kozmetik olan ortalama 2-3 böcek bulunan inceleme başına en az 16 adam saat harcadığımız ortaya çıktı. Bu sayılar karşısında akran değerlendirmelerinin yerini alacak ilk test yönteminin tartışılması kolaydı.
Berin Loritsch

Yanıtlar:


13

Kod incelemelerinin sizin için yapabileceği birkaç şey vardır ve bazı şeyler yapamazlar. Kod incelemeleri lehine yapılan argümanlar :

  • Kolektif mülkiyet
  • Hataları bul (QC)
  • Tutarlı stili uygula (KG)
  • Mentorluk

Birçok çevik süreç, bunları farklı şekillerde ele alır:

  • Toplu Mülkiyet: Takımdaki herkes projeden sorumludur, bu da herkesin gözlerinin herhangi bir zamanda kodda olacağı anlamına gelir.
  • Refactor'a ücretsiz: Bu, kod incelemelerini bir sonraki seviyeye taşır ve ekipteki herkesin gerektiğinde yeniden düzenleme yapmasına izin verir.
  • Birim testleri (QC): birim testleri, görsel incelemeden daha verimli ve insan hatasına daha az eğilimlidir. Aslında daha etkili bir yol bulamadım.
  • Çift programlama (QA): mentörlükle ilgilenir ve kod yazıldıkça erken yeniden düzenleme tavsiyeleri sağlar. Bu hala tartışmalı bir konudur, ancak yeni bir geliştiriciyi hızlandırırken yardımcı olduğunu düşünüyorum. Kodlama standartlarını uygulamak için de iyi bir zaman.

Özünde, normalde akran değerlendirmeleri yaparken sahip olacağınız potansiyel kazanımlarla ilgilenmenin başka yolları da vardır. Akran incelemeleriyle ilgili kişisel deneyimim, çok verimsiz mekanizmalar oldukları ve hataları veya daha büyük tasarım kusurlarını bulmada etkili olmadıklarıdır. Bununla birlikte, bazı takımlarda yer alırlar ve çevikliğin mümkün olmadığı projelerde (hangi nedenle olursa olsun) oldukça gereklidirler.


3
Mevcut cevapta bazı yanlış bilgiler var gibi görünüyor. Kolektif mülkiyet, "her zaman koddaki tüm gözler" anlamına gelmez. Yeniden düzenleme işleminin hata tespiti ile ilgisi yoktur. Birim testleri ve teftiş farklı amaçlara hizmet eder ve aslında her biri farklı türde kusurları ortaya çıkarabilir (diğer cevaplardaki örnekler). İkili programlama, bir inceleme şekli olsa da, örneğin Fagan denetimi için gerçek bir yedek değildir. Kişisel deneyiminiz özellikle tasarım hatalarıyla ilgili atipik görünüyor - ne tür incelemeler yaptınız? İncelemeler için verimliliği nasıl ölçtünüz?
Michael

1
Bulunan kusurlar ve bunların ciddiyetine göre zaman gerçekleştiren inceleme. Bunu birim testine karşı aynı metriklerle karşılaştırdık. Kod incelemesi sırasında keşfedilen sorunlar neredeyse her zaman kod biçimlendirmeyle ilgilidir ve gerçekleştirilmesi daha uzun sürer. Aynı zamanda birim testleri yaparak gerçek problemleri ortaya çıkardı ve artık hazırlanıp yapmadı.
Berin Loritsch

"Kolektif Mülkiyet": Deneyimlerime göre bu genellikle bir yanılsamadır: yorumcular genellikle küçük detaylarda nitpick yaparlar ve büyük resmi başkaları tarafından yazılan kodda görmezler. Daha sonra, bu kodu değiştirmek söz konusu olduğunda, kodu gerçekten anlamıyorlar ve ya (1) değiştirmeye cesaret edemiyorlar veya (2) anlayabilmeleri için kapsamlı bir şekilde yeniden yazıyorlar. Yaklaşım (2) genellikle iki yan etkiye sahiptir: (A) hatalar ortaya koyuyorlar ve (B) orijinal geliştirici artık kodu anlamıyor.
Giorgio

B Noktası, sık sık olanların kolektif mülkiyet olmadığını, bireysel sahipliğin bir geliştiriciden diğerine değiştiğini gösterir. Bu şekilde, her ekip üyesi kodun ne yaptığını ve nasıl düzenlendiğini kabaca bilir, ancak hiç kimse bunu gerçekten derinden anlamıyor. Gerçek bir toplu kod sahipliği, ortak bir anlayış elde etmek için kod hakkında çok daha fazla zaman ve tartışma gerektirecektir, ancak çoğu zaman bu kez basitçe mevcut değildir.
Giorgio

11

Kod incelemeleri sadece hataları bulmak için mi? Bunun doğru olduğunu düşünüyorsun ve ben yapmıyorum.

Kod incelemelerinin, kodun kolektif mülkiyeti hakkında daha fazla bilgi olabileceğini, bilginin birden fazla başlıkta olduğunu ve başkalarının yeni özelliklerin yanı sıra hatalar için olabilecek kodu miras almaya hazırlandığını iddia ediyorum. Kod değerlendirmeleri, birisinin konvansiyonları korumak için bir şeyin nerede yeniden yazılabileceği hakkında bir fikre sahip olabileceğini asla bilemeyeceğiniz gibi, bir kontrol ve denge sistemine sahip olmanın bir yolu olarak seviyorum.


4

Çift programlama, kod incelemelerinin XP cevabıdır. Esasen, her kod satırı yazıldığı gibi gözden geçirilir. Bu kod değerlendirmeleri aşırı alınır.


7
Bununla güçlü bir şekilde tartışırdım. Elbette, iki kişi tarafından inceleniyor, ancak bu insanlar genellikle kodun yazıldığı sayfayla aynı. Kod incelemesi, kodunuza bakarak ve "doh! Bu durumu ele almayı unutma" sorun türlerini bulmada tamamen farklı bir ruh hali olan biri - XP gerçekten bu konuda yardımcı olmuyor.
Billy ONeal

4

Kod incelemeleri ve testleri genellikle aynı tür hataları yakalamaz ve hata incelemesinin yakaladığı hataların düzeltilmesi daha kolay olur, çünkü hatanın yeri bilinir.

Kodun hiçbiri kaydedilmemiş testten geçtiği için hatasız olup olmadığını bilemezsiniz. "Test, sadece hataların varlığını kanıtlayabilir, yokluğunu kanıtlayabilir." (Dijkstra?)

Kod incelemesi de kod stilini aynı tutar ve kodun iyi olmadığı ancak şimdilik çalıştığı yerleri bulma yeteneğine sahiptir. Bakım masraflarından tasarruf sağlar.

Ayrıca, büyük bir şirketin ve bir girişimin talepleri farklıdır. Başlatmalar normalde başarısız olur ve hızlı hareket etmek zorundadır. Büyük şirketler, işleri mümkün olduğunca hızlı yapmak yerine doğru yapmaktan çok daha fazla değer kazanırlar. Başlangıçta büyük şirketlerden daha iyi çalışmayı tercih edebilirsiniz, ancak bu uygun olmadığı yerlerde başlangıç ​​stratejileri uygulamaya çalışmanın bir nedeni değildir.


2

Kod incelemelerinizde hiç UI / UX değişiklikleri var mı? Bu bir kod incelemesi değil, bir kullanılabilirlik testi olduğunu iddia ediyorum. Kod incelemeleri, kullanıcıların / test kullanıcılarının / işletmelerin / daha önce hiç görmedikleri sorunların ortaya çıkmasıyla ilgili çok daha fazlasıdır, çünkü koddadırlar. İpucu burada tam adında.

Şimdi bir yerde çizilecek bir çizgi olduğunu kabul edeceğim. Aynı kullanıcı arayüzü değişikliğinin 4 tekrarını inceliyor musunuz? Yoksa her biri kodu daha az bakım gerektirecek şekilde 4 yinelemeden mi geçiyorsunuz? Her iki yaklaşımı da ölçmeyi deneyin ve ekibiniz için doğru dengeyi bulun, ancak kod incelemelerini tamamen terk etmeyin.

Bir kod incelemesi hiçbir zaman bir sorun ortaya çıkmasa bile, orada olmayana kadar nadiren fark etmenin bir yararı vardır: her kod parçasına iki geliştirici tarafından bakılır, bu nedenle iki geliştirici değişikliğin ne olduğunu ve neyi başarmayı amaçladığını bilir . Birisi ertesi gün hastalanır ve bir haftalığına kapalı kalır, diğeri yaptıkları herhangi bir acil işi alabilir.


1

TDD ve CI ile birlikte toplu kod sahipliği ve eşleşmesinin resmi kod inceleme oturumlarına yönelik Agile panzehirleri olduğunu kabul etme eğilimindeyim.

UP / Spiral altında bile belirli bir işlem adımının büyük bir hayranı değildim "kod incelemesi" çünkü bana bulması muhtemel sorunların türü, aynı enerjinin daha önce bazı yatırımlara yatırılması durumunda olabileceklerinden daha sonra bulundu işbirliği ve bazı basit otomasyon.

Ben hissettim çünkü: - tasarım bazı paylaşılan gözden geçirme (genellikle en azından bir beyaz tahta üzerinde UML ifade) büyük ölçekli tasarım sorunları veya API'lerin kötü kullanımı, vb çok kod yazılmadan önce yakalanmak anlamına geliyordu. - FxCop, CheckStyle, FindBugs (veya benzeri), adlandırma, stilistik, görünürlük, kod çoğaltma vb.

Daha önce başarısız olmamız ve bir alt kod inceleme alışkanlığının üreteceğinden daha hızlı geri bildirim almayı başardık.

Oturup kod tabanınıza arada bir göz atmak için zaman kaybı olduğunu söylemiyorum, ancak kod incelemesini, bir şeyleri çağırmak için bir kapı adımı haline getirmek, devam eden bir sürü iş yaratıyor gibi görünüyor yukarı akışta daha iyi denetim / işbirliği ile önlendi


0

Kod incelemelerinden beklediğim temel hedeflerden biri, kod bakım kolaylığını artırmaktır. Kod incelemeleri, herkesin iyi kodlama standartlarına uygun açık kod yazmasına yardımcı olmalıdır. Çoğu kod özellikle büyük şirketlerde çok fazla bakım alır. Korunabilir kod için geri ödeme, kod serbest bırakılmadan önce başlamalı ve daha sonra devam etmelidir.

Kendi başlarına kod incelemeleri asla kod değişikliklerine neden olmamalıdır. Kod incelemesi değişikliklerin gerekli olduğunu belirtirse, değişikliğin uygulanması kodda değişikliğe neden olur.

İnceleme sonucunda kod durumu değişebilir, ancak bu, bahsettiğiniz sorunlarla çoğunlukla alakasız olmalıdır.

Kod incelemesi birden fazla kod değişikliğine neden oluyorsa, geliştirme işleminizde bir şey bozulur. Sahip olduğunuz testçilerin sayısı göz önüne alındığında, duvarın üzerinden atmak olabilir ve testçilerin sorunlu zihniyeti bulmasına izin verin.

İşler tamamlanmış durumda test edicilere gitmelidir. Testlerin mümkün olduğu kadar çok sayıda otomatikleştirilmesi gerekir, böylece test kullanıcıları zaman zaman aynı şeyleri tekrar test etmezler.

UI / UX bazı test süreleri gerektirir, ancak ön uçta tasarım / geliştirme uzmanlarına sahip olmak bunu azaltmalıdır. Ayrıca ekranın önünde bir yüz gerektirir. Bununla birlikte, çalıştığım tüm uygulamalarda, kodun nispeten küçük bir kısmıydı.

Değişiklikleri uygulama maliyeti (hata düzeltmeleri dahil) genellikle geçtiği her aşama için artar. Geliştirme sırasında hata bulmak genellikle onları bulduktan sonra onları düzeltmekten daha ucuzdur.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.