Teste Dayalı Geliştirme'nin (ve genel olarak Çevik) bu kısıtlaması pratik olarak uygun mudur?

Test Odaklı Gelişim'de (TDD) düşük kaliteli bir çözümle başlar ve daha sonra test vakaları ekleyerek ve yeniden düzenleyerek yinelemeli olarak daha iyi sonuçlar verirsiniz. Adımların küçük olması gerekiyordu, bu da her yeni çözümün bir şekilde öncekinin mahallesinde olacağı anlamına geliyor.

Bu, gradyan iniş veya yerel arama gibi matematiksel yerel optimizasyon yöntemlerine benzer. Bu tür yöntemlerin iyi bilinen bir sınırlaması, küresel olarak optimum, hatta kabul edilebilir bir yerel optimum bulmayı garanti etmemeleridir. Eğer başlangıç ​​noktanız kabul edilebilir tüm çözümlerden büyük bir kötü çözüm bölgesi tarafından ayrılırsa, oraya gitmek imkansızdır ve yöntem başarısız olacaktır.

Daha açık olmak gerekirse: Birkaç test vakası uyguladığınız bir senaryo düşünüyorum ve ardından bir sonraki test vakasının rekabet açısından farklı bir yaklaşım gerektireceğini düşünüyorum. Önceki çalışmalarınızı atmanız ve tekrar başlamak zorunda kalacaksınız.

Bu düşünce aslında sadece TDD'ye değil, küçük adımlarla ilerleyen tüm çevik yöntemlere uygulanabilir. TDD ile yerel optimizasyon arasındaki bu önerilen analojinin herhangi bir ciddi kusuru var mı?

Bu tür yöntemlerin iyi bilinen bir sınırlaması, küresel olarak optimum, hatta kabul edilebilir bir yerel optimum bulmayı garanti etmemeleridir.

Karşılaştırmalarınızı daha yeterli kılmak için: bazı problemler için, yinelemeli optimizasyon algoritmalarının iyi yerel optimasyon yapma olasılığı çok yüksektir, bazı durumlarda, başarısız olabilirler.

Birkaç test vakası uyguladığınız ve ardından bir sonraki test vakasının rekabet açısından farklı bir yaklaşım gerektireceğini belirten bir senaryo düşünüyorum. Önceki çalışmalarınızı atmanız ve tekrar başlamak zorunda kalacaksınız.

Bunun gerçekte olabileceği bir durum hayal edebiliyorum: yanlış mimariyi bir şekilde seçtiğinizde, mevcut tüm testlerinizi sıfırdan yeniden oluşturmanız gerekir. İlk 20 test durumunuzu işletim sistemi A'daki X programlama dilinde uygulamaya başladığınızı varsayalım. Ne yazık ki, 21 numaralı gereksinim, tüm programın X'in bulunmadığı B işletim sisteminde çalışması gerektiğini içerir. Bu nedenle, çalışmalarınızın çoğunu atmanız ve Y dilinde yeniden uygulamalısınız. (Elbette, kodu tamamen atmazsınız, ancak yeni dile ve sisteme taşırsınız.)

Bu bize TDD kullanırken bile, genel bir analiz ve tasarım yapmak için iyi bir fikir olduğunu öğretiyor. Bununla birlikte, bu başka bir yaklaşım için de geçerlidir, bu yüzden bunu içsel bir TDD sorunu olarak görmüyorum. Ve gerçek dünyadaki programlama görevlerinin çoğu için standart bir mimari seçebilir (programlama dili X, işletim sistemi Y, donanım XYZ'deki veritabanı sistemi Z gibi) ve TDD gibi yinelemeli veya çevik bir metodoloji olduğundan emin olabilirsiniz. seni çıkmaz bir yere getirmeyecek.

Robert Harvey'den alıntı yaparak : "Birim testlerinden mimarlık alamazsınız." Veya pdr: "TDD sadece en iyi nihai tasarıma gelmeme yardımcı olmuyor, daha az denemede oraya gitmeme yardımcı oluyor."

Yani aslında ne yazdın

Eğer başlangıç ​​noktanız kabul edilebilir tüm çözümlerden büyük bir kötü çözüm bölgesi tarafından ayrılırsa, oraya gitmek imkansızdır ve yöntem başarısız olacaktır.

gerçek olabilir - yanlış bir mimari seçtiğinizde, istenen çözüme oradan ulaşamayacaksınız.

Öte yandan, önceden genel bir planlama yaptığınızda ve doğru mimariyi seçtiğinizde, TDD'yi kullanmak, "global maksimum" seviyesine (veya en azından yeterince iyi bir maksimum değere) ulaşmayı bekleyebileceğiniz bir alanda yinelemeli bir arama algoritması başlatmak gibi olmalıdır. ) birkaç devirde.

TDD'nin yerel bir maksima problemi olduğunu sanmıyorum. Yazdığınız kod, doğru bir şekilde fark ettiğiniz gibi olabilir, ancak bu nedenle yeniden düzenleme (işlevselliği değiştirmeden kodu yeniden yazma) yerindedir. Temel olarak, testleriniz arttıkça, testler sayesinde davranışı değiştirmeden tutmanız gerekirse, nesne modelinizin önemli bölümlerini yeniden yazabilirsiniz. Sisteminiz hakkındaki değişmez gerçekleri test eder , bu nedenle hem yerel hem de mutlak maksima'da geçerli olması gerekir.

TDD ile ilgili problemlerle ilgileniyorsanız, sıklıkla düşündüğüm üç farklı durumdan bahsedebilirim:

1. Tamlık sorun: Tamamen bir sistemi tanımlamak için gerekli olan kaç testler? "Örnek olaylarla kodlama" bir sistemi tanımlamanın tam bir yolu mu?

2. Sertleşme sorunu: arayüzü test ne olursa olsun, değişmez bir arayüze sahip olması gerekir. Testler değişmez gerçekleri temsil eder , hatırla. Ne yazık ki, bu gerçekler yazdığımız kodların çoğu için bilinmemektedir, en iyi ihtimalle sadece dış cepheler için.

3. Test hasar sorun: test edilebilir iddialarda bulunan amacıyla, biz (örneğin, yeterli performansı) yazma Suboptimal koduna gerekebilir. Testleri, kodun olabildiğince iyi olması için nasıl yazarız?

Bir yorumu ele almak için düzenlenmiş: işte yeniden yapılandırma yoluyla "çifte" bir işlev için yerel bir maksimum çıkarmanın bir örneği

Test 1: giriş 0 olduğunda, sıfırla

Uygulama:

function double(x) {
  return 0; // simplest possible code that passes tests
}

Yeniden düzenleme: gerekli değil

Test 2: giriş 1 olduğunda, 2 döndür

Uygulama:

function double(x) {
  return x==0?0:2; // local maximum
}

Yeniden düzenleme: gerekli değil

Test 3: giriş 2 olduğunda, 4 döndür

Uygulama:

function double(x) {
  return x==0?0:x==2?4:2; // needs refactoring
}

yeniden düzenleme:

function double(x) {
  return x*2; // new maximum
}

Matematiksel terimlerle tanımladığınız şey, kendinizi bir köşeye boyamak olarak adlandırdığımız şeydir. Bu oluşum TDD'ye özel değildir. Şelalede, aylarca küresel toplayıcıyı yalnızca oraya ulaşabileceğini görüp, bir sonraki tepenin üstünde daha iyi bir fikir olduğunu anlayacağınızı ümit ederek gereksinimlerinizi toplayabilir ve aktarabilirsiniz.

Aradaki fark, çevik bir ortamda asla bu noktada mükemmel olmasını beklemiyorsunuzdur, bu nedenle eski fikri atmaya ve yeni fikre geçmeye hazırsınız.

TDD'ye daha spesifik olarak, TDD'nin altına özellikler eklerken bunun size olmasını engelleyen bir teknik var. Bu var Dönüşüm Öncelik Önerme . TDD'nin sizin refactor için resmi bir yolu varsa, bu özellik eklemek için resmi bir yoldur.

In Onun cevabını , @Sklivvz ikna edici sorun var olmadığını iddia etti.

Önemli olmadığını iddia etmek isterim: genel olarak yinelemeli metodolojilerin ve özellikle de Çevik ve özellikle TDD'nin temel öncül (ve doğurganlığı), yalnızca küresel optimum değil, yerel optimumlar da. bilinen değil. Yani, başka bir deyişle: bu bir problem olsa bile, yinelemeli bir şekilde yapmanın bir yolu yoktur. Temel öncülü kabul ettiğinizi varsayarsak.

TDD ve Çevik uygulamalar optimum bir çözüm üretme sözü verebilir mi? (Ya da "iyi" bir çözüm?)

Tam olarak değil. Ancak bu onların amacı değil.

Bu yöntemler basitçe, bir durumdan diğerine "güvenli geçiş" sağlayarak değişikliklerin zaman alıcı, zor ve riskli olduğunu kabul eder. Her iki uygulamanın da amacı, uygulamanın ve kodun gereklilikleri daha hızlı ve daha düzenli bir şekilde yerine getirebildiğinden emin ve kanıtlanmış olmasını sağlamaktır.

... [TDD] gereksinimleri karşılamadığı kanıtlanmış bir yazılımın eklenmesine izin veren yazılım geliştirmeye karşı çıkıyor ... 2003'te TDD'nin basitçe teşvik ettiği bir teknik geliştirdi veya 'yeniden keşfediyor' olarak kabul edilen Kent Beck güven tasarlar ve ilham verir. ( Wikipedia )

TDD, kodun her bir öbeğinin gereksinimlerini karşıladığından emin olmaya odaklanır. Özellikle, gereksinimlerin zayıf kodlama tarafından yönlendirilmesine izin vermek yerine, önceden var olan gereksinimleri karşılayan kodun sağlanmasına yardımcı olur. Ancak, uygulamanın herhangi bir şekilde "optimal" olduğuna dair hiçbir söz vermemektedir.

Çevik süreçlere gelince:

Çalışan yazılım, ilerlemenin birincil ölçütüdür ... Her yinelemenin sonunda, paydaşlar ve müşteri temsilcisi yatırımın geri dönüşünü optimize etmek amacıyla ilerlemeyi gözden geçirir ve öncelikleri yeniden değerlendirir ( Wikipedia )

Çeviklik optimal bir çözüm aramıyor ; Sadece çalışan bir çözüm - YG'yi optimize etme niyetiyle . Bu bir çalışma çözüm vaat er ziyade sonra ; "optimal" bir değil.

Ancak, bu tamam, çünkü soru yanlış.

Yazılım geliştirmedeki en uygun olanlar bulanık ve hareketli hedeflerdir. İhtiyaçlar genellikle akıcıdır ve patronunuzun patronlarıyla dolu bir konferans odasında utanç duymanız için ortaya çıkan sırlarla doludur. Ve bir çözümün mimarisinin ve kodlamasının "içsel iyiliği", meslektaşlarınızın ve genel yönetimsel yöneticinizin ayrık ve öznel görüşleri ile derecelendirilir - hiçbiri iyi yazılım hakkında hiçbir şey bilemeyebilir.

En azından yılında TDD ve Çevik uygulamaları zorlukları kabul edip iki şey için optimize girişimi olan objektif ve ölçülebilir: . Çalışma v Değil-Çalışma ve Er v Sonra..

Ve nesnel ölçütler olarak "çalışıyor" ve "daha erken" olsa bile, onlar için optimize etme yeteneğiniz öncelikle bir ekibin becerisine ve deneyimine bağlıdır.

Bunu şeyler olabilir çabaları üretmek olarak kurmada en uygun çözümleri gibi şeyler şunlardır:

• KATI ilkeleri
• Kodu temizle
• Tasarım desenleri
• Yetenekli ve deneyimli insanları işe almak ...

vb..

_{Bunların her birinin gerçekten en uygun çözümleri üretip üretmediği sorulacak başka bir soru olacaktır!}

Şimdiye kadar kimsenin eklemediği şeylerden biri, tarif ettiğiniz "TDD Geliştirme" nin çok soyut ve gerçekçi olmadığıdır. Bir algoritmayı optimize ettiğiniz matematiksel bir uygulamada olabilir ama çoğu kodlayıcının üzerinde çalıştığı iş uygulamalarında bu çok fazla olmaz.

Gerçek dünyada, testleriniz temel olarak İş Kurallarını kullanıyor ve onaylıyor:

Örneğin - Bir müşterinin karısı ve iki çocuğuyla sigara içmeyen 30 yaşında olması durumunda, premium kategori "x" vb.

Prim hesaplama motorunu çok uzun süre doğru olana kadar tekrarlı bir şekilde değiştirmeyeceksiniz - ve uygulama kesinlikle canlıyken kesinlikle değil;).

Gerçekte yarattığınız şey, bir güvenlik ağıdır, böylece belirli bir müşteri kategorisi için yeni bir hesaplama yöntemi eklendiğinde, eski kuralların tümü aniden kırılmaz ve yanlış cevaplar vermez. Güvenlik ağı, hata ayıklamanın ilk adımı, hatayı düzeltmek için kod yazmadan önce hatayı üreten bir test (veya bir dizi test) oluşturmaksa daha da faydalıdır. Ardından, bir yıl, eğer birisi yanlışlıkla testten önce kod testinden önce kesilen orijinal hatayı yeniden yaratırsa. Evet, TDD'nin izin verdiği tek şey, artık büyük bir yeniden düzenleme ve düzenli bir şekilde güvenli bir şeyler yapabilmenizdir. ama bu işinin büyük bir parçası olmamalı.

Öyle olacağını sanmıyorum. Çoğu takım, beyaz tahtaya yazmış olsanız bile, optimal bir çözüm bulabilecek hiç kimseye sahip değildir. TDD / Agile yoluna çıkmayacak.

Birçok proje optimal çözümler gerektirmez ve bu konuda gerekli zaman, enerji ve odaklanma yapılacaktır. Yapmaya meyilli olduğumuz her şey gibi, ilk önce çalışmasını sağlayın. O zaman hızlı yap. Performans bu kadar önemliyse bunu bir çeşit prototiple yapabilir ve daha sonra her şeyi birçok yinelemeyle edinilen bilgelikle yeniden inşa edebilirsiniz.

Birkaç test vakası uyguladığınız ve ardından bir sonraki test vakasının rekabet açısından farklı bir yaklaşım gerektireceğini belirten bir senaryo düşünüyorum. Önceki çalışmalarınızı atmanız ve tekrar başlamak zorunda kalacaksınız.

Bu olabilir, ancak gerçekleşmesi daha muhtemel olan, uygulamanın karmaşık kısımlarını değiştirme korkusu. Herhangi bir test yaptırmamak, bu alanda daha büyük bir korku duygusu yaratabilir. TDD'nin ve testlerin bir avantajına sahip olmanın avantajlarından biri, bu sistemi değiştirilmeye ihtiyaç duyduğu nosyonuyla kurmanızdır. En başından beri bu yekpare optimize edilmiş çözümle karşılaştığınızda, değiştirilmesi çok zor olabilir.

Ayrıca, bunu optimizasyon eksikliğinizin bağlamı içine koyun ve sahip olmamanız gereken şeyleri optimize etmek ve esnek olmayan çözümler oluşturmak için zaman harcayamazsınız, çünkü performanslarına çok odaklandığınız için yardım edemezsiniz.

"Lokal optimum" gibi matematiksel kavramları yazılım tasarımına uygulamak aldatıcı olabilir. Bu tür terimlerin kullanılması, yazılım geliştirmenin gerçekte olduğundan çok daha nicel ve bilimsel görünmesini sağlar. Kod için "optimum" bulunsa bile, onu ölçmek için bir yöntemimiz yoktur ve bu nedenle de ulaşıp ulaşmadığımızı bilmenin bir yolu yoktur.

Çevik hareket, yazılım geliştirmenin matematiksel yöntemlerle planlanabileceği ve tahmin edilebileceği inancına karşı bir tepkiydi. Daha iyi veya daha kötüsü için, yazılım geliştirme bir bilimden ziyade bir sanat eseri gibidir.