Çift programlama, bir Extreme Programming (XP) projesinde kod inceleme ihtiyacını ortadan kaldırıyor mu?

Aşırı bir programlama projesinde, programcılar çoğu zaman çift programlama yaparlar.

Bu çiftler de döndükçe, yani programı farklı insanlarla eşleştiriyorsunuz ve kolektif bir sahiplenme duygusu var, kaynak kodu sık sık gözden geçiriliyor ve güncelleniyor.

Bu nedenle, kod incelemelerine ihtiyaç var mı? Yani, programlamayı durdurun ve aslında sadece kod incelemeleri yapın.

— Eduardo Copat
kaynak

Çift programlama XP'nin yalnızca kiracısıdır. XP'yi takip etmeyen birçok çevik yöntem var. Agile Yazılım Geliştirme Manifestosu'nda veya Agile Manifestosunun arkasında Prensipler'de çift programlamadan bahseden hiçbir şey yoktur . Kod incelemeleri hakkında da hiçbir şey yok. Tüm çeviklerin aşırı olduğunu varsaymamak önemlidir.

O zaman sadece XP'yi dahil etmek için sorumu tekrar yazayım.

— Eduardo Copat

Denememenizin ve durmak için bazı kriterler belirlediğinizden emin olmanızın bir nedeni var mı? Eğer takım check-in yapmaktan memnunsa, bu yeterince iyi bir sebep olmalıdır.

— JeffO

Extreme Programming için anahtar kaynaklardan biri Ward's Wiki, yani Portland Pattern Repository, yani C2.com . Burası birçok insanın çeşitli metodolojileri ortaya çıkardığı ve kullandıkları gibi belgelediği yerdir.

Bu wiki içinde bir sayfa var: Ron Jeffries ve Kent Beck dahil olmak üzere bir takım katkıda bulunan Aşırı Programlama Kodu İncelemeleri .

Bunun için dediler ki:

Kod incelemeleri, birçok büyük işlem gurusu tarafından önemli kabul edilir. Standartlara uygunluğu ve daha da önemlisi, kodun açık, verimli, çalışır ve QWAN'a sahip olmasını sağlamayı amaçlamaktadırlar. Ayrıca, kod hakkındaki bilgilerin ekibin geri kalanına yayılmasına yardımcı olmayı amaçladılar.

ExtremeProgramming, tüm geliştirmelerin birlikte çalışan iki mühendis tarafından yapılmasını gerektirir. Kod aslında oldukça büyük ölçüde anında gözden geçirilir. Bu, birden fazla kişinin her zaman kod hakkında samimi bilgiye sahip olmasını sağlar.

ExtremeProgramming, tüm nesnelerin UnitTest'lerine sahip olmasını gerektirir. Bunlar nesnenin çalışmasını ve değiştirildiği gibi çalışmaya devam etmesini sağlar.

Bazı diller yansıtıcıdır. Bu dillerde, UnitTests doğrudan önemli standartların uygunluğunu kontrol edebilir. (örneğin, nesneler # = ve #hash değerlerini uygulamalı veya hiçbirini uygulamamalıdır.)

ExtremeProgramming uygulamaları, dikkat gerektiren nesnelere birçok geliştirici tarafından göz atılacağı anlamına gelen CollectiveCodeOwnership uygulamaları. Bu, standartlara uymayan kod üreten kodlara baskı yapma eğilimindedir. Ziyaret eden geliştiriciler, sapma bulduklarında kodu uygunluğa getirmeleri için teşvik edilir / beklenir. Bu aynı zamanda kod bilgisinin onu oluşturan ilk programcı çiftinin ötesine yayılmasını sağlar.

Bu nedenle, ExtremeProgramming projeleri açık incelemeler gerektirmez. Onları metodolojinizden çıkarın.

Bu konuda başkalarından biraz daha fazla tartışma var.

Önemli noktalar, testlerin, işbirlikçi sahipliğin ve bu programların çiftinin bir araya getirilmesiyle, bir kod incelemesinin tipik olarak yapması gereken hedefleri çözmesidir:

Ne yapıldığının bilgisini dağıtın
Standartlara uyduğundan emin olmak için koddaki ikinci (veya daha fazla) göz küresi seti
Kodun doğru çalıştığını doğrulayın

Bunlar, Extreme Programming'de çift programlama ve otomatik testler yoluyla sürekli olarak yapılmaktadır ve bu nedenle açık bir Fagan denetimi gerekli değildir.

İlgili okumalar:

Kodlama Korku Programlama vs Kod İnceleme çifti .
Kod İncelemeleri ExtremeProgramming.org adresinde Hurtful olarak değerlendirildi

Başka bir q & a kod inceleme gereksiz bir atık olduğunu (kelimenin Yalın anlamda) ve bu programlama programlama bir kod inceleme sağlayacağı tüm faydaları sağlamak için tercih edilen bir yöntem olması gerektiğini savundu. Söylemeye gerek yok, insanlar benim iddialarıma saldırdı çünkü ben sizin gibi YETKİ SESİNİ (TM) desteklememiştim. Her gün mantıkla uğraşan bir grup insan için mantıksız bir grubuz.

— Michael Brown

Ek kod incelemeleri olmadan çift programlama yapma riski, her iki programcının yazma anında yoğun bir şekilde yer alması ve o zaman tamamen net ve mantıklı görünen, ancak birkaç gün sonra tekrar görüldüğünde daha az kod yazabilmeleridir. Bu riskin ne kadar büyük ve / veya kabul edilebilir olduğu kuruluşunuza bağlıdır.

— Bart van Ingen Schenau

@MikeBrown, Eşli Programlamanın gereksiz bir atık olduğunu ve kod incelemesinin vb.

— Olması

ATIK ile kastettiğime bak, kelimenin "Yalın" tanımı idi. Tipik montaj hattı sürecini düşünün. Fikir, aracı olabildiğince çabuk aşağı indirmektir ve bundan sonra kalite kontrolleri yapılır (kod incelemesi). Yalın ilkeler, kaliteyi oluşturmak için biraz daha fazla zaman ve çaba harcar (çift programlama), böylece post kontrolü gereksiz hale gelir.

— Michael Brown