Mengapa MVC & TDD tidak dipekerjakan lebih banyak dalam arsitektur game? [Tutup]

Saya akan mengawali ini dengan mengatakan saya belum melihat sumber permainan dalam jumlah besar, atau membangun banyak di jalan permainan.

Tapi datang dari mencoba menggunakan praktik pengkodean 'perusahaan' di aplikasi web, melihat kode sumber permainan benar-benar menyakitkan kepala saya: "Apa yang dilakukan logika pandangan ini dengan logika bisnis? "

Ini membuat saya khawatir karena saya akan memulai sebuah proyek game, dan saya tidak yakin apakah mencoba mvc / tdd proses dev akan menghambat kami atau membantu kami, karena saya tidak melihat banyak contoh game yang menggunakan ini atau banyak dorongan untuk praktik arsitektur yang lebih baik di masyarakat.

Berikut ini adalah kutipan dari artikel hebat tentang game prototyping , meskipun bagi saya sepertinya sikap yang tampaknya banyak digunakan para game dev ketika menulis kode game produksi:

Kesalahan # 4: Membangun sistem, bukan permainan

... jika Anda pernah menemukan diri Anda mengerjakan sesuatu yang tidak secara langsung memajukan Anda, berhenti di situ. Sebagai pemrogram, kami memiliki kecenderungan untuk mencoba menggeneralisasi kode kami, dan membuatnya elegan dan dapat menangani setiap situasi. Kami menemukan bahwa gatal sangat sulit tidak tergores, tetapi kita perlu belajar caranya. Butuh waktu bertahun-tahun untuk menyadari bahwa ini bukan tentang kode, ini tentang permainan yang Anda kirim pada akhirnya.

Jangan menulis sistem komponen permainan yang elegan, lewati editor sepenuhnya dan sembunyikan status dalam kode, hindari kegilaan XML yang didorong data, self-parsing, XML, dan hanya kode hal yang terkutuk itu.

... Dapatkan barang-barang di layar secepat mungkin.

Dan jangan pernah, gunakan argumen "jika kita mengambil waktu ekstra dan melakukan ini dengan cara yang benar, kita dapat menggunakannya kembali dalam permainan". PERNAH.

apakah itu karena game (sebagian besar) berorientasi visual sehingga masuk akal bahwa kode akan sangat terbebani dalam pandangan, sehingga setiap manfaat dari memindahkan barang ke model / pengendali, cukup minim, jadi mengapa repot-repot?

Saya telah mendengar argumen bahwa MVC memperkenalkan overhead kinerja, tetapi menurut saya ini adalah optimasi prematur, dan bahwa ada masalah kinerja yang lebih penting untuk ditangani sebelum Anda khawatir tentang overhead MVC (mis. Render pipeline, algoritma AI, datastructure traversal, dll).

Hal yang sama tentang TDD. Saya jarang melihat permainan menggunakan test case, tetapi mungkin ini disebabkan oleh masalah desain di atas (tampilan campuran / bisnis) dan kenyataan bahwa sulit untuk menguji komponen visual, atau komponen yang mengandalkan hasil probablistik (misalnya beroperasi dalam simulasi fisika ).

Mungkin saya hanya melihat kode sumber yang salah, tetapi mengapa kita tidak melihat lebih banyak praktik 'perusahaan' yang digunakan dalam desain game? Apakah game benar-benar berbeda dalam persyaratannya, atau apakah ada masalah orang / budaya (mis. Game dev datang dari latar belakang yang berbeda dan karenanya memiliki kebiasaan pengkodean yang berbeda)?

Seperti kata kutipan, banyak programmer membuat kesalahan dengan (mencoba) membangun sistem, bukan permainan. Biasanya sistem itu terus menggelembung di luar kendali sampai begitu rumit sehingga secara teoritis dapat menangani apa pun, tetapi dalam praktiknya yang Anda miliki hanyalah sekumpulan besar kode. Atau lebih sering, bahkan sebelum Anda sampai pada tahap kerja, Anda begitu terjerat dalam kode yang tidak berjalan sehingga Anda kehilangan fokus (jika Anda memiliki awal) dan motivasi (karena tidak ada yang benar-benar bekerja).

Prototipe dan iterasi cenderung bekerja lebih baik. Pada akhirnya, sebuah desain yang bagus mungkin keluar dari sana, tetapi lebih sering sesuatu yang lebih sederhana dan halus keluar darinya. KISS dan YAGNI muncul di pikiran.

Saya pribadi percaya perlu ada keseimbangan. Jika ada mekanik inti permainan Anda, kerjakanlah. Anda masih perlu mengulang, tetapi Anda harus memperbaikinya. Petunjuk: pengorganisasian kode Anda bukan mekanik inti dari game Anda.

Contoh kasus: Peggle , oleh PopCap Games. Mekanik inti permainan ini adalah fisika bola. Mereka menyempurnakannya! Saya yakin mereka menghabiskan banyak waktu memastikan itu benar-benar sempurna, karena itulah yang membuat permainan. Tetapi pada saat yang sama, saya benar-benar bisa membayangkan prototipe awal permainan mereka yang mungkin hanya menggambar sprite ke layar dan melakukan beberapa jenis deteksi tabrakan yang lebih primitif dan memantul, hanya untuk melihat apakah ide permainan itu menyenangkan. Kemudian begitu mereka mengetahui bahwa menembak bola dan melihatnya memantul benar-benar bisa menyenangkan, mereka memperhalus bola yang memantul. _{(Ini semua hanya spekulasi, tentu saja)}

Ini juga tergantung pada persyaratan teknis Anda, yang harus Anda tempuh sejak dini (bukan desain game Anda, hanya persyaratan teknis). Platform tempat permainan Anda seharusnya tidak berubah, atau jika harus dibiarkan berubah, Anda harus tahu persis sejauh mana Anda berencana untuk mengubahnya, tidak lebih dan tidak kurang. Desain itu. Jika Anda mengembangkan game untuk OpenGL, dan Anda tidak peduli dengan DirectX, maka sungguh, jangan pedulikan itu. Itu berarti bahwa jika lebih mudah bagi Anda untuk membuat setiap entitas menggambar sendiri dan tidak khawatir tentang Pabrik dan pola desain lainnya seperti itu, maka lakukan itu. Tidak apa-apa, karena memenuhi persyaratan. Anda tidak harus mengubahnya nanti, terlepas dari apa yang Anda katakan pada diri sendiri. Dan sungguh, skenario terburuk? Reaktor nanti., mendapatkan gim yang berfungsi pada satu platform bahkan jika itu berarti gim tersebut tidak dapat secara bersamaan dan otomatis berjalan pada pemanggang Anda.

Desain yang digerakkan oleh tes, bagaimanapun, adalah topik yang lebih banyak pendapat. Saya berkeyakinan bahwa pengembang game harus melakukan lebih dari itu. Saya juga berpikir pengembang game memiliki beberapa jadwal yang paling ketat dan ketat, dan mereka pikir mereka tidak mampu menghabiskan waktu di TDD ketika mereka hanya ingin menjalankan permainan. Juga, sekali lagi dengan motivasi, TDD jauh lebih lambat dan Anda bisa melihat jauh lebih sedikit permainan yang berfungsi (setidaknya pada awalnya). Ini dapat memiliki efek negatif serius pada motivasi programmer.

Saya pikir itu juga hanya kurangnya pengetahuan dan praktik secara umum. Saya tidak berpikir TDD lazim di daerah lain juga, tetapi seperti pengembangan gesit, saya pikir itu menyebar. Anda mungkin mengatakan ini lebih awal dari waktunya (atau mungkin tidak, karena kasusnya mungkin bertahun-tahun dari sekarang). Lebih penting daripada TDD adalah "RDD" - Pengembangan Kebutuhan Didorong. _{Saya hanya mengada-ada.}Apa tujuanmu? Untuk membuat game. Yang lainnya menempati urutan kedua. Jika Anda dapat membuktikan bahwa TDD meningkatkan produktivitas dan membantu tim mencapai tenggat waktu, bukankah Anda pikir semua orang akan menggunakannya? Dan mungkin itu masalahnya. Tapi sekarang, industri kita lebih kompetitif dari sebelumnya, ada tenggat waktu yang lebih keras dan lebih cepat, dan hal-hal hanya perlu bekerja. Pekerja konstruksi tidak membangun perancah terlebih dahulu; mereka meletakkan fondasi, kemudian mereka menaikkan beberapa dinding dan lantai, dan hanya kemudian mereka membangun potongan perancah selektif untuk melakukan tugas-tugas khusus yang perancah membuat lebih nyaman. Saya pikir hal yang sama berlaku untuk pengembangan perangkat lunak.

Maaf untuk posting yang sangat panjang. Saya harap Anda mendapatkan sedikit hikmah darinya. Saya hanya seorang siswa, berbicara tentang pengamatan saya, dengan pengalaman industri yang sangat terbatas tetapi banyak membaca dari para pakar industri. Jadi ambillah kata-kata saya dengan sebutir garam.

Dan hei, lakukan apa yang menurut Anda akan berhasil. Anda selalu dapat mengubahnya atau memo dan mulai lagi dari awal. Itulah hal keren tentang segala bentuk rekayasa; jika pada awalnya Anda tidak berhasil, coba sesuatu yang berbeda. (atau sesuatu seperti itu :-P) Anda tidak menuangkan beton; perangkat lunak dapat ditempa.

Ngomong-ngomong, saya sudah menanyakan jenis pertanyaan yang sama dan meneliti jenis-jenis prinsip desain ini untuk beberapa waktu. Berikut adalah beberapa pertanyaan, baik di sini maupun di Stack Overflow, yang mungkin Anda temukan relevan:

• "Bagaimana kamu bisa mengatur kode untuk game agar sesuai dengan pola MVC?"
• "Bagaimana cara mendesain perangkat lunak game sehingga mudah untuk unit test?"
• "Desain mesin gim berbasis komponen"
• "Adakah tutorial atau sumber daya yang bagus untuk belajar bagaimana merancang kerangka kerja game berbasis" komponen "yang scalable dan?"
• "Pemisahan logika permainan dan rendering"
• "Apakah pengujian unit layak dalam pemrograman game?"
• "Apakah pola desain MVC digunakan dalam game komputer komersial"
• "Apakah pengembangan yang digerakkan tes merupakan pendekatan normal dalam pengembangan game?"
• "Apakah ada di antara kamu yang menggunakan Scrum untuk pengembangan game?"
• "Arsitektur untuk Game - Untuk berpasangan atau tidak berpasangan?"
• "Pertanyaan desain game OO"

Inilah jawaban asli saya untuk pertanyaan serupa tentang SO sejak beberapa waktu lalu, setidaknya mengenai bagian MVC dari pertanyaan Anda:

Ini jarang digunakan dalam game. Butuh beberapa saat untuk mencari tahu mengapa, tapi inilah pikiran saya:

MVC ada untuk membuat perbedaan antara dua representasi. Model adalah representasi abstrak dari data Anda. Begitulah cara mesin melihat kondisi aplikasi Anda. The View (and Controllers) merepresentasikan instantiasi nyata yang lebih nyata dari sistem itu dengan cara yang berarti bagi manusia.

Di sebagian besar aplikasi bisnis, kedua dunia ini sangat berbeda. Misalnya, model spreadsheet hanyalah kotak nilai 2D. Tidak perlu memikirkan seberapa lebar sel dalam piksel, di mana bilah gulir berada, dll. Pada saat yang sama, tampilan spreadsheet tidak tahu bagaimana nilai sel dihitung atau disimpan.

Dalam sebuah game, kedua dunia itu jauh lebih dekat satu sama lain. Dunia permainan (model) biasanya seperangkat entitas yang diposisikan di beberapa ruang virtual. Tampilan game juga merupakan seperangkat entitas yang diposisikan di beberapa ruang virtual. Mengikat volume, animasi, posisi, dll., Semua hal yang Anda anggap bagian dari "tampilan" juga langsung digunakan oleh "model": animasi dapat memengaruhi fisika dan AI, dll.

Hasil akhirnya adalah bahwa garis antara model dan tampilan dalam permainan akan berubah-ubah dan tidak membantu: Anda akan menduplikasi banyak status di antara mereka.

Sebagai gantinya, game cenderung memisahkan hal-hal di sepanjang batas domain: AI, fisika, audio, render, dll. Akan disimpan terpisah mungkin.

Karena MVC tidak cocok dengan arsitektur permainan. Aliran data untuk game sepenuhnya berbeda dari aplikasi enterprice, karena itu bukan sebagai event-driven dan sering kali ada anggaran milidetik yang sangat ketat untuk menjalankan operasi ini. Ada banyak hal yang perlu terjadi dalam 16,6 milidetik sehingga lebih menguntungkan untuk memiliki pipa data 'tetap' dan kaku yang memproses data yang Anda butuhkan di layar dalam waktu yang tepat.

Juga, pemisahan ada di sana; sebagian besar waktu itu tidak terhubung dengan cara yang sama seperti pola MVC. Ada mesin rendering (View), penanganan input pengguna (Controller) dan sisanya seperti gameplay logic, ai, dan physics (Model). Pikirkan tentang itu; jika Anda mengambil input pengguna, menjalankan ai dan merender gambar 60 kali per detik, lalu mengapa Anda membutuhkan Pengamat antara model dan tampilan untuk memberi tahu Anda apa yang telah berubah? Jangan menafsirkan ini sebagai saya mengatakan bahwa Anda tidak memerlukan pola Pengamat dalam permainan, Anda memang perlu, tetapi dalam hal ini Anda benar-benar tidak. Anda melakukan semua pekerjaan itu, setiap frame.

Meskipun TDD hampir tidak pernah digunakan di studio pengembangan, kami menggunakan praktik Agile menuju pengembangan perangkat lunak dan SCRUM tampaknya menjadi pilihan populer setidaknya di Eropa. Alasannya sederhana, perubahan datang dari mana-mana. Para seniman mungkin menginginkan lebih banyak anggaran tekstur, dunia yang lebih besar, lebih banyak pohon sementara perancang menginginkan cerita yang lebih kaya (lebih banyak konten pada disk), dunia streaming dan penerbit ingin Anda selesai tepat waktu, dan sesuai anggaran, demikian pula departemen pemasaran. Dan terlepas dari itu, "keadaan seni" terus berubah dengan cepat.

Itu tidak berarti bahwa kami juga tidak melakukan pengujian, sebagian besar studio memiliki departemen T&J yang besar, menjalankan banyak tes regresi dan melakukan tes unit secara teratur. Namun, hampir tidak ada gunanya melakukan tes unit di muka karena sebagian besar bug terkait dengan seni / grafis (lubang pada tabrakan bertabrakan, tekstur yang salah apa pun, kesalahan dalam kedalaman bidang shader) yang tidak dapat dicakup oleh pengujian unit. Dan selain kode kerja, faktor terpenting dari setiap gim adalah menyenangkan, dan tidak ada unit yang mengujinya.

Juga ingat bahwa di dunia konsol ini masih berbeda, karena Anda memprogram lebih banyak untuk perangkat keras daripada untuk hal lain. Ini umumnya (PS2 / PS3) berarti bahwa aliran data jauh lebih penting daripada aliran kode di hampir setiap kasus; karena pertimbangan kinerja. Yang membatalkan penggunaan TDD sebagai alat arsitektur dalam banyak kasus. Kode OOP yang baik umumnya memiliki aliran data yang buruk, sehingga sulit untuk membuat vektor dan memparalelkan.

Mengapa MVC & TDD tidak dipekerjakan lebih banyak dalam arsitektur game?

Peringatan: opini di depan.

MVC tidak digunakan (banyak) karena:

1. MVC adalah pendekatan yang relatif baru dan permainan biasanya dibangun di atas kode lama. Kebanyakan orang yang membuat aplikasi MVC membangunnya dari ketiadaan setiap saat. (Saya tahu MVC sendiri sebenarnya berumur puluhan tahun; apa yang baru adalah minat luas di dalamnya, yang pada dasarnya berasal dari aplikasi web seperti RoR). Dalam perangkat lunak bisnis yang saya kerjakan yang didasarkan pada kode warisan, tidak ada gunanya untuk MVC di sana. Ini adalah masalah budaya, tetapi tidak khusus untuk game.
2. MVC pada dasarnya adalah pola GUI untuk program yang digerakkan oleh acara. Game tidak didominasi oleh GUI atau dikendalikan oleh peristiwa, oleh karena itu penerapannya tidak sebagus untuk aplikasi web atau aplikasi berbasis formulir lainnya. MVC biasanya merupakan pola Pengamat dengan beberapa peran terkenal, dan gim seringkali tidak memiliki kemewahan menunggu untuk mengamati sesuatu yang menarik - mereka harus memperbarui segala sesuatu setiap frame (atau beberapa variasi pada itu) apakah ada yang mengklik sesuatu atau tidak .

Bukan berarti game tidak bisa belajar banyak dari MVC. Saya selalu mencoba dan memisahkan model dari tampilan dalam game yang saya buat. Ide tradisional view dan controller menjadi 2 bagian dari objek (widget) yang sama tidak benar-benar berfungsi, jadi Anda harus sedikit lebih abstrak tentang hal itu. Saya setuju dengan Anda bahwa kinerja tidak mungkin menjadi masalah nyata di sini. Jika kinerja apa pun dapat mengambil manfaat dari menjaga hal-hal visual dan hal-hal logika terpisah karena itu lebih cocok untuk cache koherensi, paralelisme, dll.

TDD tidak digunakan (banyak) karena:

1. Benar-benar canggung untuk digunakan dalam gim. Sekali lagi, tidak masalah untuk perangkat lunak yang digerakkan oleh peristiwa di mana input masuk dan output keluar dan Anda dapat membandingkan apa yang Anda lihat dengan yang Anda harapkan dan mencentangnya sebagai benar. Untuk simulasi dengan sejumlah besar keadaan bersama, ini secara signifikan lebih aneh.
2. Tidak ada bukti yang tak terbantahkan bahwa itu membantu apa pun. Hanya banyak klaim, dan beberapa angka seringkali didasarkan pada pelaporan diri dan naik banding ke otoritas. Mungkin ini membantu programmer yang buruk menjadi biasa-biasa saja tetapi menahan programmer yang baik. Mungkin waktu yang dihabiskan untuk menulis tes bisa lebih baik dihabiskan untuk mempelajari prinsip-prinsip SOLID, atau merancang antarmuka yang benar. Mungkin memberikan rasa aman yang salah untuk melakukan tes yang lolos tanpa bukti nyata bahwa Anda memiliki cukup tes untuk memastikan objek Anda melakukan hal yang benar.

Sekali lagi, sebagai peringatan, saya pikir unit test sangat bagus, tetapi saya tidak berpikir "test first" itu menguntungkan atau masuk akal. Saya juga tidak berpikir itu praktis untuk menguji simulasi utama ketika ada begitu banyak keadaan yang diubah berkali-kali per detik. Saya membatasi tes saya pada level rendah dan kode perpustakaan saya, secara umum.

Namun, seperti yang mungkin bisa Anda tebak, saya sebagian besar bias terhadap "praktik pengkodean '' perusahaan '" karena perusahaan terkenal karena melampaui rentang waktu dan anggaran. "Begitu juga pengembang game!" Saya mendengar Anda berkata - yah, ya. Saya tidak berpikir ada orang yang benar-benar tahu cara terbaik untuk mengembangkan perangkat lunak saat ini dan saya tidak yakin bahwa mengadopsi praktik-praktik yang diatur dalam perangkat lunak utama sama sekali merupakan langkah maju dari praktik-praktik yang lebih bebas dalam perangkat lunak hiburan. Bahkan saya menduga itu terutama bermanfaat bagi mereka yang bergantung pada komoditas pemrogram Java di mana pendekatan ini bukan tangga untuk naik ke ketinggian yang lebih tinggi tetapi jaring pengaman untuk menghentikan mereka jatuh terlalu rendah.

Seperti yang dicatat oleh Kylotan, "Dalam game, Anda tidak dapat memperlakukan aspek presentasi sebagai konsep yang dapat dilepas dan diganti seperti HTML dan CSS untuk aplikasi web". Setelah membangun beberapa game menggunakan pola MVC sederhana (bukan kerangka besar) saya telah menemukan masalah utama adalah bahwa model Anda perlu tahu tentang pandangan Anda. Sangat mungkin bahwa Anda perlu menggunakan data bitmap sprite, data hitbox atau data geometri 3D dari aset seni Anda untuk membantu menyelesaikan deteksi tabrakan (atau tugas serupa lainnya). Ini berarti setiap model memerlukan referensi untuk pandangannya, yang mematahkan pola MVC klasik - misalnya Anda tidak lagi dapat membuat tampilan baru ke model yang ada dll.

Model komponen yang Anda lihat misalnya Unity3D adalah cara terbaik untuk mengatur kode game.

MVC, pada beberapa level, sudah digunakan dalam pengembangan game. Dipaksa oleh OS, yang memiliki antarmuka berbeda untuk input dan grafik. Sebagian besar gim juga memiliki beberapa contoh MVC di dalamnya, misalnya memisahkan fisika dan merender serta memasukkan utas. Ini berfungsi dengan baik. Gagasan modern MVC tampaknya adalah bahwa itu harus diulang, secara fraktal, sampai tidak ada yang bisa memahami kode lagi. Untungnya, permainan tidak melakukan itu.

TDD tidak digunakan karena jarang dikenal permainan "seharusnya dilakukan" sebelum Anda mengulangi prototipe berkali-kali. Praktik dari TDD, seperti pengujian berkelanjutan atau pengujian integrasi, sering digunakan dalam pengembangan game.

Sistem gim perlahan-lahan beralih ke praktik yang lebih baik. Kerangka kerja seperti XNA memberikan wawasan tentang membuat kode lebih umum / bersih tanpa menambahkan terlalu banyak overhead dalam desain atau waktu eksekusi. Tetapi secara umum saya akan mengatakan bahwa sistem game adalah tentang mengoptimalkan kompleksitas vs kecepatan eksekusi, semua tetap pada jadwal pengembangan yang ketat dan tetap termotivasi. Menerapkan konsep rekayasa perangkat lunak dan desain sistem bukan prioritas nomor 1 di lingkungan seperti itu.

Dalam proyek gim pribadi saya, saya mencoba mengomentari kode atau setidaknya membuatnya dapat dibaca, dan saya menyatukan sistem yang akan memungkinkan sedikit lebih banyak kelenturan nanti (yaitu generalitas) sebanyak mungkin, tetapi pada akhirnya, jika Anda belum memajukan game Anda, rasanya tidak enak.

Juga biasanya pada saat Anda menyelesaikan permainan Anda, Anda punya setidaknya 1000 ide tentang bagaimana meningkatkan mekanika yang mendasarinya, sistem inti, dll, sedemikian rupa sehingga sangat sedikit dari kode "yang dapat digunakan kembali" akan benar-benar dapat digunakan. Pada siang hari saya melakukan pekerjaan SE biasa, dan sementara sistem yang kami kerjakan mungkin sangat besar, sejujurnya saya pikir mereka pucat dibandingkan dengan kompleksitas dalam permainan.

Saya tidak memiliki pendapat khusus tentang MVC di luar kenyataan bahwa pandangan sering dipisahkan dari logika oleh fakta sederhana bahwa render loop sedang mengemas banyak barang untuk diproses beberapa perangkat keras dan itu bukan tempat di mana Anda ingin "permainan" logika "terjadi secara bersamaan. "Pengontrol" juga dipisahkan oleh perangkat keras, tetapi sayangnya banyak jika tidak sebagian besar pengembang game melakukan pekerjaan "menarik" di pengendali pengendali. (IMO pengendali pengendali harus membaca tombol dan tongkat dan membuat "presentasi" untuk dilihat permainan, tetapi kotak sabun saya tidak sekuat itu.)

TDD di sisi lain adalah sesuatu yang saya punya pendapat yang sangat kuat. Itu hanya mengubah pengembangan dengan cara menghasilkan perangkat lunak yang lebih mudah dibangun. Itu lebih sulit untuk dilakukan, tidak diragukan lagi. Tentu saja, karena lebih sulit untuk dilakukan, itu tidak dilakukan. Beberapa orang mengeluh tentang TDD (atau lebih umum pengujian unit) tidak memiliki nilai karena "permainan adalah ujian," tetapi kenyataannya adalah bahwa dalam TDD, pengujian hampir tidak relevan. Inti dari TDD adalah desain dan arsitektur perangkat lunak yang keluar dari proses.

Merangkul TDD benar-benar mengubah pendekatan seseorang terhadap pemrograman. Saya memiliki perasaan tentang apa yang benar dan apa yang salah sebelum saya memulai jalan TDD, tetapi begitu saya melompat dengan kedua kaki saya benar-benar memahami lebih banyak tentang bagaimana hal-hal yang saya lakukan baik membantu atau menghambat perkembangan masa depan. . Memang, ini adalah semacam titik di belakang postingan coderoom, TDD tanpa t .

Kembali ke mengapa itu tidak digunakan lebih banyak dalam permainan, selain sulit, itu membuat orang menyadari bahwa cara mereka selalu melakukannya di masa lalu membuat pekerjaan mereka sendiri menjadi lebih sulit, dan bagi para programmer terutama itu pil pahit untuk dilihat, apalagi menelan.

Saya yakin bahwa orang yang menolak untuk menerima TDD tidak ingin menjadi programmer yang lebih baik. Mereka sudah berpikir bahwa mereka "hebat" dalam pemrograman atau desain atau arsitektur, padahal sebenarnya kode mereka mengatakan sesuatu yang sama sekali berbeda.