MVC ve TDD neden oyun mimarisinde daha fazla kullanılmıyor? [kapalı]

Bunu çok fazla oyun kaynağına bakmadığımı ya da oyun tarzına çok fazla bakmadığımı söyleyerek başlatacağım.

Ancak, web uygulamalarında 'kurumsal' kodlama uygulamalarını kullanmaya çalışmaktan, oyun kaynak koduna bakmak ciddi bir şekilde beni incitiyor: "Bu iş mantığı ile iş mantığı arasında ne yapıyor? Bu yeniden düzenleme ihtiyacı ... "

Bu, beni bir oyun projesi başlatmak üzere olduğum için endişelendiriyor ve dev işleminin mvc / tdd'yi denemeye çalışacağından emin değilim. Bunu kullanan pek çok oyun örneği görmedim, ya da toplumda daha iyi mimari uygulamalar için daha fazla itici.

Aşağıdakiler prototip oyunlarıyla ilgili harika bir makalenin özetidir , ancak bana göre birçok oyun geliştiricinin üretim oyun kodu yazarken kullandıkları tutum tam olarak görünüyordu:

Hata # 4: Bir sistem kurmak, oyun değil

... doğrudan ileriye doğru hareket etmeyen bir şey üzerinde çalışırken kendinizi bulursanız, orada durun. Programcılar olarak, kodumuzu genelleştirmeye ve onu şık hale getirme ve her durumu ele alma yeteneğine sahibiz. Kaşıntıyı çizilmemesi zor buluyoruz ama nasıl yapılacağını öğrenmemiz gerekiyor. Kodla ilgili olmadığını, sonunda göndereceğiniz oyunla ilgili olduğunu fark etmek yıllar aldı.

Zarif bir oyun bileşeni sistemi yazmayın, editörü tamamen atlayın ve durumu kodda sabitleyin, veriye dayalı, kendiliğinden ayrıştırma, XML çılgınlığı ve sadece lanet olası şeyi kodlayın.

... Ekranda olabildiğince çabuk şeyler olsun.

Ve bir daha asla, “biraz fazla zaman alır ve bunu doğru şekilde yaparsak, oyunda yeniden kullanabiliriz” argümanını kullanmayın. HİÇ.

Oyunlar (çoğunlukla) görsel olarak yönlendirilmiş olduğu için kodun görünümde ağır şekilde ağırlıklandırılması mantıklıdır, bu nedenle eşyaların modellere / denetleyicilere taşınmasının getirdiği faydalar oldukça azdır, bu yüzden neden rahatsız edici?

MVC'nin genel bir performans artışı getirdiği iddiasını duydum, ancak bu bana erken bir optimizasyon gibi görünüyor ve MVC genel giderleriyle ilgili endişelenmeden önce ele almanız gereken daha önemli performans sorunları olduğunu düşünüyorum (örn. Boru hattı oluşturma, AI algoritmaları, veri yapısı geçiş, vb.)

TDD için de aynı şey. Sık sık test senaryoları kullanan oyunlar görmüyorum, ama belki de bunun nedeni yukarıdaki tasarım sorunlarından (karma görüş / iş) ve görsel bileşenleri veya olasılıksal sonuçlara dayanan bileşenleri test etmenin zorluğundan kaynaklanıyor (örneğin fizik simülasyonları içinde çalışmak). ).

Belki de sadece yanlış kaynak koduna bakıyorum, ama neden oyun tasarımında kullanılan bu 'işletme' uygulamalarını daha fazla göremiyoruz? Oyunlar gereklilikleri bakımından gerçekten çok mu farklı mı yoksa bir insan / kültür sorunu mu var (yani, oyun geliştiricileri farklı bir arka plandan geliyor ve bu nedenle farklı kodlama alışkanlıklarına sahipler)?

Alıntıya göre, pek çok programcı bir oyun değil, bir sistem inşa etmeyi (hata yapmayı) yapıyor. Tipik olarak, bu sistem teorik olarak her şeyi halledebilecek kadar karmaşık olana kadar balonun dışına taşmaya devam eder , ancak pratikte sahip olduğunuz tek şey büyük bir kod demetidir. Ya da daha sık, bir çalışma aşamasına geçmeden önce, o kadar karışıksınız ki, hiçbir şey işe yaramazsa, odaklanmayı kaybetmeniz (eğer baştan başaracak olsaydınız) ve motivasyonunuz yok.

Prototipler ve yineleme çok daha iyi çalışma eğilimindedir. Sonunda, harika bir tasarım ortaya çıkabilir, ancak daha sık ve daha basit ve zarif bir şey ortaya çıkar. KISS ve YAGNI akla geliyor.

Şahsen dengenin olması gerektiğine inanıyorum. Oyununun temel bir teknisyeni varsa, üzerinde çalış. Hala yinelemeye ihtiyacın var, ama düzeltmelisin. İpucu: Kodunuzun düzenlenmesi, oyununuzun temel bir tamircisi değildir.

Konuya ilişkin örnek: PopCap Games tarafından Peggle . Oyunun temel bir tamircisi top fiziğidir. Mükemmelleştirdiler! Kesinlikle mükemmel olduklarından emin olmak için çok zaman harcadıklarından eminim, çünkü oyunu yapan da bu. Ama aynı zamanda, sadece ekrana sprite çeken ve sadece oyun fikrinin eğlenceli olup olmadığını görmek için ilkel çarpışma algılama ve zıplayan bir tür prototipini tamamen hayal edebiliyorum. Sonra bir top atmanın ve onu zıplatmanın izlemesinin gerçekten eğlenceli olabileceğini öğrendikten sonra, topun zıplamasını geliştirdiler. _{(elbette hepsi bu spekülasyondur)}

Aynı zamanda erken çektiğiniz teknik gereksinimlerinize de bağlıdır (oyun tasarımınıza değil sadece teknik gereksinimlere). Oyununuzun üzerinde çalıştığı platform değişmemeli veya değişmesine izin verilmesi gerekiyorsa, değişmesine izin vermeyi planladığınızı bilmeniz gerekir, daha fazla ve daha az değil. Bu konuda tasarım. OpenGL için bir oyun geliştiriyorsanız ve DirectX'i umursamıyorsanız, o zaman gerçekten umursamayın. Bunun anlamı, eğer her bir işletmenin kendisini çizmesi ve Fabrikalar ve bunun gibi diğer tasarım kalıpları için endişelenmemesi daha uygunsa, o zaman bunu yap. Sorun değil, çünkü şartları yerine getiriyor. Kendine söylediklerine rağmen, daha sonra değiştirmek zorunda kalmamalısın. Ve gerçekten, en kötü durum senaryosu? Daha sonra refactor., aynı anda ve otomatik olarak ekmek kızartma makinenizde çalışamayacağı anlamına gelse bile, bir platformda çalışma oyunu edinme.

Ancak test odaklı tasarım daha fazla tartışılan bir konudur. Oyun geliştiricilerin daha fazlasını yapması gerektiğine inancım var. Ayrıca oyun geliştiricilerin en katı ve sıkı programlardan bazılarına sahip olduğunu ve sadece bir oyun başlatmak istediklerinde TDD'de zaman geçirmeyi göze alamayacaklarını düşünüyorlar. Ayrıca, yine motivasyonla TDD çok daha yavaştır ve işleyen bir oyunu daha az görürsünüz (en azından başlangıçta). Bunun programcı motivasyonu üzerinde ciddi olumsuz etkileri olabilir.

Bunun sadece genel bir bilgi ve uygulama eksikliği olduğunu düşünüyorum. TDD'nin diğer alanlarda da yaygın olduğunu düşünmüyorum, ancak çevik gelişme gibi yayıldığını da düşünüyorum. Onun vaktinden önce diyebilirsin (ya da belki de, yıllar sonra olabileceği gibi). TDD'den daha önemli olan "RDD" dir - Gereksinimler Odaklı Geliştirme. _{Ben uydurdum.}Amacın ne? Bir oyun yapmak için. Her şey ikinci gelir. TDD'nin üretkenliği arttırdığını ve ekiplerin son teslim tarihlerine ulaşmalarına yardımcı olduğunu kanıtlarsanız, herkesin kullanacağını düşünmüyor musunuz? Ve belki de durum budur. Ancak şu anda, endüstrimiz her zamankinden daha rekabetçi, daha zor ve daha erken tarihler var ve işlerin sadece çalışması gerekiyor. İnşaat işçileri önce iskele yapmazlar; bir temel atıyorlar, sonra bazı duvarları ve döşemeleri kaldırıyorlar ve ancak o zaman iskelenin daha uygun hale getirdiği belirli işleri yapmak için seçici iskele parçaları yapıyorlar. Aynı durumun yazılım geliştirme için de geçerli olduğunu düşünüyorum.

Uzun bir yazı için üzgünüm. Umarım ondan bir miktar bilgelik kazanmışsındır. Ben sadece bir öğrenciyim, gözlemlerim hakkında konuşuyorum, çok sınırlı endüstri tecrübesine sahip, ancak endüstri uzmanlarından çok fazla okuma yapıyorum. Bu yüzden sözlerimi bir tuz tuzu ile alın.

Ve hey, işe yarayacağını düşündüğün şeyi yap. Her zaman değiştirebilir veya hurdaya çıkarabilir ve baştan başlayabilirsiniz. Her türlü mühendislik hakkında harika olan şey budur; ilk başta başaramazsan, farklı bir şeyler dene. (ya da bunun gibi bir şey :-P) Beton dökmüyorsunuz; yazılımı dövülebilir.

Bu arada, ben de aynı soruyu soruyorum ve bu tasarım prensiplerini bir süredir araştırıyorum. Hem burada hem de Stack Overflow'ta alakalı bulabileceğiniz bazı sorular:

• "MVC modeline uyacak bir oyun için kodu nasıl düzenleyebilirsiniz?"
• "Bir oyunun yazılımını, ünite testini kolaylaştıracak şekilde nasıl tasarlayabilirim?"
• "Komponent tabanlı oyun motoru tasarımı"
• “Ölçeklenebilir ve“ bileşen ”tabanlı bir oyun“ çerçeve ”nin nasıl tasarlandığını öğrenmek için herhangi bir iyi öğretici veya kaynak var mı?”
• "Oyunun ayrılması ve render mantığı"
• "Oyun programlamasında birim testi uygulanabilir mi?"
• "Ticari bilgisayar oyunlarında MVC tasarım deseni kullanılıyor mu"
• "Test geliştirme, oyun geliştirmede normal bir yaklaşım mıdır?"
• “Herhangi biriniz oyun geliştirme için Scrum kullanıyor mu?”
• "Oyun için Mimari - Çiftleşmek ya da çiftleşmemek?"
• "OO oyun tasarımı soru"

En azından sorunuzun MVC kısmıyla ilgili olarak, SO hakkında bir süredir benzer bir soruya orijinal cevabım :

Oyunlarda nadiren kullanılır. Nedenini bulmam biraz zaman aldı, ama işte düşüncelerim:

MVC, iki temsil arasında bir ayrım yapmak için vardır. Model, verilerinizin soyut temsilidir. Makine uygulamanızın durumunu nasıl görüyor? Görünüm (ve Kontrolörler) bu sistemin insanlar için anlamlı bir şekilde daha somut görünür bir örneğini temsil ediyor.

Çoğu iş uygulamasında, bu iki dünya oldukça farklıdır. Örneğin, bir elektronik tablonun modeli basitçe bir 2D değer ızgarasıdır. Hücrelerin piksel cinsinden ne kadar geniş olduğunu, kaydırma çubuklarının nerede olduğunu vb. Düşünmek zorunda değildir. Aynı zamanda, elektronik tablo görünümü hücre değerlerinin nasıl hesaplandığını veya depolandığını bilmez.

Bir oyunda, bu iki dünya birbirine çok daha yakın. Oyun dünyası (model) tipik olarak bazı sanal alanlara yerleştirilmiş bir grup varlıktır. Oyun görünümü aynı zamanda bazı sanal alanlara yerleştirilmiş bir dizi varlıktır. Sınırlayıcı hacimler, animasyon, konum vb. "Görünümün" bir parçası olarak düşüneceğiniz her şey doğrudan "model" tarafından da kullanılır: animasyon fiziği ve yapay zekayı vb. Etkileyebilir.

Sonuç, bir oyunda model ve görünüm arasındaki çizginin keyfi ve yararlı olmayacağı: sonuçta aralarında çok fazla durumun çoğalmasıyla sonuçlanacaksınız.

Bunun yerine, oyunlar nesneleri sınır sınırları boyunca ayırma eğilimindedir: AI, fizik, ses, render vb. Mümkün olduğu kadar ayrı tutulacaktır.

Çünkü MVC bir oyunun mimarisine uymuyor. Bir oyun için veri akışı, işletme girişimi uygulamasından tamamen farklıdır, çünkü bu bir olay tarafından yönlendirilen bir etkinlik değildir ve bu işlemlerin gerçekleştirileceği bir (çok) sıkı milisaniye bütçesi vardır. 16.6 milisaniyede yapılması gereken pek çok şey var, bu yüzden tam olarak o sırada ekranda ihtiyacınız olan verileri işleyen 'sabit' ve katı bir veri hattına sahip olmak daha faydalı.

Ayrıca, ayırma oradadır; çoğu zaman sadece MVC modeli ile aynı şekilde kablolanmamıştır. Bir işleme motoru (Görünüm), kullanıcı girişi işleme (Kontrolör) ve oyun mantığı, AI ve fizik (Model) gibi geri kalanlar vardır. Bunu düşün; kullanıcı girişi alıyorsanız, ai'yi çalıştırıyorsanız ve görüntüyü saniyede 60 kez görüntülüyorsanız, o zaman neyin değiştiğini söyleyebilmek için model ile görünüm arasında bir Gözlemciye ihtiyacınız olsun? Bunu oyunlarda Gözlemci desenine gerek duymadığınızı söylediğim gibi yorumlama, yaparsınız, ama bu durumda gerçekten yapmazsınız. Zaten bütün bu işleri, her kareyi yapıyorsun.

TDD geliştirme stüdyolarında pek kullanılmasa da, yazılım geliştirmeye yönelik Çevik uygulamaları kullanıyoruz ve SCRUM en azından Avrupa'da en popüler seçenek olarak gözüküyor. Nedeni basit, değişiklikler her yerden geliyor. Sanatçılar daha fazla doku bütçesi, daha büyük dünyalar, daha fazla ağaç, tasarımcılar daha zengin bir hikaye (diskte daha fazla içerik), akışkan bir dünya ve yayıncılar, zamanında ve bütçeyle ilgili olarak bitirmenizi ister ve pazarlama departmanı isteyebilir. Ve bunun dışında, "sanatın durumu" hızla değişmeye devam ediyor.

Bu da test etmediğimiz anlamına gelmiyor, çoğu stüdyoda büyük soru-cevap departmanları var, birçok regresyon testi yapıyor ve düzenli olarak birim testleri yapıyorlar. Bununla birlikte, ünite testlerini açıkça yapan herhangi bir nokta yoktur, çünkü böceklerin büyük bir kısmı sanat / grafiklerle ilgilidir (çarpışma ağlarındaki delikler, yanlış dokular ne olursa olsun, alan gölgelendiricisinin derinliklerindeki aksaklıklar) ünite testlerinin üstesinden gelemez. Ve çalışma kodunun yanı sıra, herhangi bir oyunun en önemli faktörü eğlenceli olması ve bunu test eden birimin olmaması.

Ayrıca, konsol dünyasında bunun daha da farklı olduğunu unutmayın, çünkü donanım için daha sonra başka şeyler için daha fazla programlıyorsunuzdur. Bu genellikle (PS2 / PS3) veri akışının hemen her durumda kodun akışından çok daha önemli olduğu anlamına gelir; performans hususları nedeniyle. Bu, çoğu durumda TDD'nin mimari bir araç olarak kullanılmasını geçersiz kılar. İyi OOP kodu genellikle kötü veri akışına sahiptir, bu da vektörleştirmeyi ve paralelleştirmeyi zorlaştırır.

MVC ve TDD neden oyun mimarisinde daha fazla kullanılmıyor?

Uyarı: görüş ileride.

MVC kullanılmıyor (çok) çünkü:

1. MVC nispeten yeni bir yaklaşımdır ve oyunlar genellikle eski kod üzerine kuruludur. MVC uygulamaları yapan çoğu kişi, onları her zaman hiçbir şeyden inşa etmiyor. (MVC'nin aslında onlarca yıllık olduğunu biliyorum; yeni olan, esasen RoR gibi web uygulamalarından gelen, yaygın ilgisi.) Üzerinde çalıştığım iş yazılımında eski kodlara dayanıyordu, orada da MVC'nin bir faydası yoktu. Bu bir kültür meselesi ama oyuna özgü değil.
2. MVC, olay odaklı programlar için temel olarak bir GUI modelidir. Oyunlar ne GUI ağırlıklı ne de etkinlik odaklı değillerdir, dolayısıyla uygulanabilirlik web uygulamaları veya diğer form tabanlı uygulamalar için olduğu kadar iyi değildir. MVC tipik olarak bazı iyi bilinen rollere sahip Gözlemci kalıbıdır ve oyunlar genellikle ilginç bir şeyi gözlemlemeyi beklemenin lüksüne sahip değildir - herhangi birinin herhangi bir şeyi tıklayıp tıklamadığına bakılmaksızın her kareyi (ya da bunun bir varyasyonunu) her şeyi güncellemeleri gerekir. .

Bu, oyunların MVC'den çok fazla şey öğrenemediği anlamına gelmez. Modeli her zaman yaptığım oyunların görünümünden ayırmaya çalışırım. Görünüm ve denetleyicinin geleneksel (aynı widget) nesnenin 2 bölümü olduğu fikri aslında işe yaramıyor, bu yüzden biraz daha soyut olmalısınız. Performansın burada gerçek bir sorun olamayacağı konusunda size katılıyorum. Herhangi bir performans görsel ve mantıksal şeyleri ayrı tutmanın faydalarından yararlanabilirse, önbellek tutarlılığı, paralellik vb. İçin daha elverişlidir.

TDD kullanılmıyor (çok) çünkü:

1. Oyunlarda kullanmak gerçekten garip. Yine, girdilerin girdiği ve çıktıların çıktığı olay odaklı yazılımlar için iyidir ve beklediklerinizle karşılaştığınız şeyi karşılaştırabilir ve doğru olarak işaretleyebilirsiniz. Büyük miktarlarda paylaşımlı duruma sahip simülasyonlar için bu çok daha garip.
2. Hiçbir şeye yardımcı olduğuna dair tartışılmaz bir kanıt yok. Sadece çok fazla talep ve bazı rakamlar sıklıkla kendi kendine raporlamaya dayanır ve otoriteye hitap eder. Belki de kötü programcıların vasat olmasına yardımcı olur, ancak iyi programcıları geride tutar. Belki de testler için harcanan zaman, SOLID ilkelerini öğrenerek veya ilk olarak doğru arayüzü tasarlayarak daha iyi harcanabilir. Belki de, nesnenizin doğru olanı yapmasını sağlamak için yeterli testlere sahip olduğunuza dair gerçek bir kanıt olmadan geçen testlerin yapılması yanlış bir güvenlik hissi verir.

Yine, bir ihtar olarak, birim testlerinin mükemmel olduğunu düşünüyorum, ancak “önce test” in yararlı veya mantıklı olduğunu düşünmüyorum. Aynı zamanda, saniyede birçok kez değişen çok fazla ortak durum olduğunda ana simülasyonu test etmenin pratik olmadığını düşünüyorum. Testlerimi genellikle düşük seviyeme ve kütüphane kodumla sınırlandırıyorum.

Ancak, muhtemelen tahmin edebileceğiniz gibi, işletmeler zaman aşımına uğrayan zaman çizelgelerine ve bütçelerine göre iyi biliniyor olduğu için "işletme" kodlama uygulamalarına "karşı büyük ölçüde önyargılıyım. "Öyleyse oyun geliştiricileri yap!" Dediğini duydum - evet, evet. Şu an hiç kimsenin şu anda yazılım geliştirmenin en iyi yolunu bildiğini sanmıyorum ve genel amaçlı yazılımda düzenli uygulamalar benimsemenin eğlence yazılımındaki daha özgür uygulamalardan bir adım ötede olduğuna ikna olmadım. Aslında, öncelikle, bu yaklaşımların daha yükseklere tırmanmak için bir merdiven değil, çok düşük düşmelerini engellemek için bir güvenlik ağı olan emtia Java programcılarına güvenenler için faydalı olduğunu düşünüyorum.

Kylotan'ın da belirttiği gibi, "Oyunlarda sunum yönünü HTML ve CSS gibi ayrılabilir ve değiştirilebilir bir kavram olarak değerlendiremezsiniz" web uygulamaları içindir. Basit bir MVC deseni kullanarak birkaç oyun kurdum (çok büyük bir çerçeve değil) En büyük sorunu, modelinizin görüşünüz hakkında bilmesi gereken bir şey buldum. Çarpışma algılamasını (veya benzeri bir görevi) çözmenize yardımcı olmak için sanat varlıklarınızdan sprite bitmap verilerini, hitbox verilerini veya 3D geometri verilerini kullanmanız gerekebilir. Bu, her modelin klasik MVC modelini kıran görünümüne bir referansa ihtiyacı olduğu anlamına gelir - örneğin, mevcut bir modele artık yeni bir görünüm oluşturamazsınız vb.

Unity3D'de gördüğünüz bileşen modeli, oyun kodunu düzenlemenin en iyi yoludur.

MVC, bazı seviyelerde oyun geliştirmede zaten kullanılıyor. Giriş ve grafikler için farklı arayüzleri olan işletim sistemi tarafından zorlanır. Oyunların çoğunda ayrıca birkaç MVC örneği daha vardır, örneğin fiziği ayırma ve görüntü oluşturma ve giriş konuları. Bu iyi çalışıyor. MVC'nin modern fikri, hiç kimse kodu anlayamayana kadar fraktal olarak tekrarlanması gerektiği gibi görünüyor. Oyunlar bunu yapmaz, minnetle.

TDD kullanılmaz, çünkü nadiren bir oyunun bir prototipte tekrarlamadan önce "yapması gerekiyor" olarak bilinir. Sürekli test veya entegrasyon testi gibi TDD uygulamaları genellikle oyun geliştirmede kullanılır.

Oyun sistemleri daha iyi uygulamalar için yavaşça ilerliyor. XNA gibi çerçeveler, tasarım veya uygulama süresinde çok fazla ek harcamadan kodu daha genel / temiz hale getirme konusunda bir fikir sağlar. Ancak genel olarak, oyun sistemlerinin tamamının, sıkı bir geliştirme programında kalırken ve motive kalırken, yürütme hızını ve yürütme hızını optimize etmekle ilgili olduğunu söyleyebilirim. Yazılım mühendisliği kavramlarını ve sistem tasarımını uygulamak böyle bir ortamda öncelikli değildir.

Kişisel oyun projelerimde, kodu yorumlamaya ya da en azından okunabilir hale getirmeye çalışıyorum ve daha sonra biraz daha esnek (örneğin genellik) mümkün olduğunca çok, ancak günün sonunda izin verecek sistemleri bir araya getiriyorum. oyununu ilerletmedin, iyi hissetmiyorsun.

Ayrıca, genellikle oyununuzu bitirdiğiniz zaman, temel mekaniği, çekirdek sistemleri vb. Bu "yeniden kullanılabilir" kodun çok azının kullanacağı şekilde geliştirmek için en az 1000 fikriniz var. gerçekten kullanışlı ol. Gün geçtikçe düzenli bir SE işi ​​yapıyorum ve üzerinde çalıştığımız sistemler devasa olsa da, dürüst olmak gerekirse, oyunların karmaşıklığına kıyasla soluk olduklarını düşünüyorum.

MVC'nin görüşün genellikle mantıktan, oluşturma döngüsünün bir takım donanımın işleyebilmesi için bir sürü şeyi bir araya getirdiği ve istediğin yer değil oyun olduğu gerçeğiyle ayrıldığı gerçeği dışında hiçbir fikrim yok. mantık "aynı anda oluyor. "Kontrolör" donanımla da ayrılmıştır, ancak oyun geliştiricilerin çoğu "ilginç" çalışma yapmazlarsa denetleyici işleyicisinde çalışırlar. (IMO, denetleyici işleyicisi, düğmeleri okumak ve yapışmak ve oyunun görüntüleyebilmesi için bir "sunum" yapmak zorundadır, ancak soapbox'ım o kadar güçlü değildir.)

TDD ise, hakkında çok güçlü görüşlerime sahip olduğum bir şey. Geliştirilmesi, üzerinde geliştirmesi kolay bir yazılım sağlayacak şekilde değişir. Şüphe yok, yapmak zor. Tabii ki, yapmak zor olduğundan, bitmedi. Bazı insanlar TDD (ya da daha genel olarak ünite testi) hakkında “oyun test” olduğu için hiçbir değere sahip değildir, ancak gerçek şu ki TDD'de testler neredeyse alakasızdır. TDD'nin amacı, süreçten çıkan yazılım tasarımı ve mimarisidir.

TDD'yi benimsemek, gerçekten programlama yaklaşımını değiştiriyor. TDD yoluna girmeden önce neyin doğru neyin yanlış olduğu konusunda bazı hislerim vardı, ancak bir kez iki ayağa da girdiğimde, yaptığım işlerin gelecekteki kalkınmaya nasıl yardım ettiği ya da engellediği hakkında daha çok şey anladım. . Nitekim, bu kod odası yazısının arkasındaki nokta, TDD'siz t .

Neden oyunlarda daha fazla kullanılmadığına, zor olmanın ötesine geçtikten sonra, insanların geçmişte her zaman yaptıkları gibi, kendi işlerini gereksiz yere zorlaştırdıklarını ve programcıların özellikle bakması gereken acı bir hap olduğunu fark etmelerini sağlar. çok daha az yutmak.

TDD'yi kabul etmeyi reddeden insanların daha iyi programcılar olmak istemediklerine ikna oldum. Programlamada, tasarımda veya mimaride "mükemmel" olduklarını düşünüyorlar, aslında kodları tamamen farklı bir şey söylüyor.