Mengapa "Game of Life" Conway digunakan untuk retret kode?

Code Retreat adalah acara pelatihan sepanjang hari yang berfokus pada dasar-dasar pengembangan perangkat lunak. Ada hari retret kode "global" yang akan datang, dan saya menantikannya. Yang mengatakan, saya pernah ke satu sebelumnya dan harus mengatakan ada sejumlah besar kekacauan ... yang baik-baik saja.

Satu hal yang masih belum saya dapatkan adalah mengapa "Game of Life" adalah masalah yang baik untuk TDD, dan seperti apa rasanya TDD baik dan buruk itu.

Sadarilah ini pertanyaan yang cukup terbuka, jadi jangan ragu untuk berkomentar.

Awalnya, Permainan Kehidupan Conway dipilih karena kami memiliki applet java yang siap untuk dikerjakan pada coderetreat pertama pada bulan Januari 2009. Tujuan hari itu adalah untuk bereksperimen dengan beberapa ide seputar praktik kotak waktu, dan kami hanya memilih applet GoL karena kami memilikinya.

Namun, setelah itu, sebagai pasangan fasilitator aktif (terutama saya selama perjalanan saya di tahun 2009 dan Alex Bolboaca di Bucharest) menyelidiki penggunaan GoL sebagai alat pembelajaran. Pada saat yang sama kami mengembangkan format coderetreat menjadi seperti sekarang ini. Pada tahun 2009, Alex mencoba setidaknya satu masalah lain (skor tangan poker), tetapi tidak merasa berguna seperti GoL. Anda dapat menemukan lebih banyak tentang sejarah di http://coderetreat.org/history

Coderetreat berfokus pada peningkatan pemahaman kita tentang desain sederhana (khususnya 4 aturan desain sederhana), pengembangan berbasis pengujian, dan aspek fundamental lainnya dari pengembangan perangkat lunak. GoL memiliki manfaat menjadi masalah yang sangat sederhana untuk dipahami sambil tetap sangat kaya dari perspektif struktural. Itu dengan mudah menyediakan bagian dari sistem yang dapat digunakan sebagai contoh dari semua topik yang kita praktikkan di coderetreat. Sebagai contoh, implementasi umum yang mengambil (x, y) parameter dalam banyak metode adalah peluang besar untuk berbicara tentang prinsip KERING (setiap bagian pengetahuan harus memiliki satu dan hanya satu representasi dalam sistem Anda) sehubungan dengan topologi dari sistem. Ada banyak aspek lain yang dapat digunakan sebagai contoh membangun desain yang meminimalkan biaya perubahan.

Ada beberapa orang sekarang yang telah melakukan beberapa coderetreats, dan mereka masih menemukan aspek menarik dari masalah untuk digunakan sebagai latihan.

Permainan Kehidupan Conway akan sangat cocok karena itu adalah perangkat pengkodean yang cukup sederhana yang memiliki hasil yang sangat kuat. Sedangkan untuk menggunakannya untuk menggerakkan Test-Driven Development, saya bertaruh karena tes akan cukup sulit untuk menulis karena hasil yang Anda cari tidak jelas dari kode yang Anda tulis. Menulis kode yang membuat Anda menjadi peluncur adalah trik jika Anda belum pernah melakukannya atau tidak melakukannya dalam waktu yang lama. Dengan demikian cocok untuk memperluas seni disiplin, terutama ketika dieksekusi dalam pemrograman berpasangan seperti TDD biasanya.

Sejauh mengajarkan Anda hal-hal yang berguna; ini merupakan latihan dalam pemikiran lateral. Anda harus mengonseptualisasikan bagaimana kode Anda akan berfungsi, menjalankannya, melihatnya gagal, mengumpulkan data, refactor, dan melanjutkan iterasi. Semua hal ini sangat penting untuk TDD. Menghubungkannya ke dunia nyata, itu mirip dengan klien yang menyerahkan dokumen persyaratan samar yang hanya mengatakan "Saya ingin X". Jadi Anda memberi mereka X tetapi mendapatkan X mungkin rumit. Permainan Kehidupan Conway sangat bagus dalam mengajarkan hal itu. Ini juga cukup mudah untuk dikodekan dan biasanya tidak memerlukan banyak kode untuk melakukannya. ( APL menjadi salah satu contoh implementasi yang lebih ekstrem.) Jadi, cukup cocok untuk sesi singkat yang akan diadakan lebih dari satu atau dua minggu iterasi seperti yang biasanya Anda temukan di lingkungan produksi.

Game of Life di satu sisi adalah seperangkat aturan yang sangat sederhana, di sisi lain berisi beberapa peringatan terburuk dari pemrograman tingkat lanjut, terkait dengan skalabilitas . Sementara hasilnya deterministik, ada tantangan dari lapangan bermain yang tak terbatas dan jumlah sel yang tak terbatas untuk diproses.

Jika spesifikasi tantangan mencakup kinerja minimum dan jejak memori maksimum , maka pengujian mencakup pola yang berkembang pesat, atau pola yang bergerak ke berbagai arah jauh dan luas, ini mungkin menjadi tantangan yang sangat membuat frustrasi.

Anda mendapatkan input dan output yang dikenal setelah iterasi X, dan Anda tahu semua langkah untuk sampai di sana ... kecuali langkah-langkahnya terlalu banyak dan terlalu lama. Anda harus melakukan beberapa optimasi yang cukup ekstrim agar sesuai dengan spesifikasi. Algoritma trivial dengan memindai array 2d ukuran tetap buffer ganda menjadi sangat tidak memadai karena kinerjanya menurun dengan O (n ^ 2) dari ukuran. Memperlakukan balok yang terisi saat benda baru muncul tiba-tiba memakan banyak memori dan menjadi lambat. Memisahkan semuanya menjadi papan ukuran terbatas kadang-kadang berfungsi, kadang gagal ...

Dan karena sebagian besar tes "global" akan gagal standar kinerja, Anda perlu mengembangkan tujuan yang lebih kecil, sub-tes yang lebih kecil yang membuat peringatan ...

Itu semua tergantung pada aspek proses apa yang ingin Anda latih / latih.

Satu hari saja tidak cukup untuk mencakup semua aspek rekayasa perangkat lunak terlepas dari paradigma pendekatan / manajemen proyek yang Anda pilih. Jadi untuk membuatnya efektif, Anda mungkin harus berkonsentrasi pada sebagian kecil dari keseluruhan.

Jika Anda fokus pada aspek teknis TDD misalnya maka Anda mungkin ingin melepaskan area abu-abu besar di sekitar persyaratan dan hubungan dengan pelanggan dan memotong langsung ke pengkodean solusi.

Dalam hal ini Game of Life adalah kandidat yang baik karena sederhana, dipahami dengan baik dan tidak memiliki banyak area abu-abu dalam persyaratannya yang akan terbuka untuk diperdebatkan. Dengan demikian Anda dapat mulai menulis tes Anda segera dan kode menentangnya.

Jika di sisi lain tujuannya adalah untuk melihat bagaimana kita dapat menggunakan TDD untuk mengasah persyaratan maka saya mungkin telah memilih permainan kehidupan tetapi saya tidak akan mengatakan kepada para devs bahwa inilah yang saya inginkan. Sebaliknya saya akan berkeliling memberikan petunjuk dan ide tanpa benar-benar menyebutkan namanya. Yang mengatakan permainan kehidupan mungkin agak sedikit terlalu sederhana untuk jenis latihan ini karena peserta kemungkinan besar akan melihat melalui taktik cukup cepat.

Contoh tidak selalu mudah ditemukan untuk latihan sintetis semacam itu. itu harus sederhana untuk dilakukan dalam sehari tetapi tidak terlalu mudah untuk membuatnya melalui hari. Itu harus menyenangkan tetapi tidak berarti ... Tetapi bagi saya itu harus sedikit orisinal, saya tidak dapat mengingat berapa kali saya diminta untuk membuat para siswa membuat sistem manajemen videoclub untuk pekerjaan rumah .... iiirch.