¿Por qué se utiliza el "Juego de la vida" de Conway para retiros de código?

Code Retreat es un evento de capacitación de todo el día que se centra en los fundamentos del desarrollo de software. Se acerca un día de retiro de código "global" y estoy deseando que llegue. Dicho esto, he estado en uno antes y tengo que decir que hubo una gran cantidad de caos ... lo cual está bien.

Una cosa que todavía no entiendo es por qué el "Juego de la Vida" es un buen problema para TDD, y qué tan bueno y malo es para TDD.

Tenga en cuenta que esta es una pregunta bastante abierta, así que siéntase libre de comentar.

Originalmente, se eligió Conway's Game of Life porque teníamos un applet de Java a mano para trabajar en el primer coderetreat en enero de 2009. El objetivo del día era experimentar con algunas ideas en torno a la práctica de tiempo limitado, y simplemente elegimos el applet GoL porque lo teníamos.

Después de eso, sin embargo, como un par de facilitadores activos (especialmente yo durante mi gira oficial en 2009 y Alex Bolboaca en Bucarest) investigaron los usos de GoL como herramienta de aprendizaje. Al mismo tiempo, estábamos evolucionando el formato de coderetreat a lo que se ha convertido hoy. En 2009, Alex intentó al menos otro problema (puntuación de la mano de póker), pero no lo encontró tan útil como GoL. Puede encontrar más información sobre la historia en http://coderetreat.org/history

Coderetreat se centra en mejorar nuestra comprensión del diseño simple (específicamente las 4 reglas del diseño simple), el desarrollo basado en pruebas y otros aspectos fundamentales del desarrollo de software. GoL tiene la ventaja de ser un problema muy simple de entender y, al mismo tiempo, ser muy rico desde una perspectiva estructural. Proporciona fácilmente partes del sistema que pueden usarse como ejemplos de todos los temas que practicamos en coderetreat. Por ejemplo, una implementación común que toma parámetros (x, y) en múltiples métodos es una gran oportunidad para hablar sobre el principio DRY (cada conocimiento debe tener una y solo una representación en su sistema) con respecto a la topología de sistema. Hay muchos otros aspectos que se pueden usar como ejemplos para construir un diseño que minimice el costo del cambio.

Hay bastantes personas que han realizado múltiples retratamientos de código, y todavía encuentran aspectos interesantes del problema para usar como práctica.

Game of Life de Conway encajaría bien porque es un conjunto de codificación bastante simple que tiene resultados profundamente poderosos. En cuanto a su uso para impulsar el desarrollo impulsado por pruebas, apostaría a que es porque las pruebas serían bastante difíciles de escribir porque los resultados que está buscando no son obvios en el código que está escribiendo. Escribir código que te dé un planeador es un buen truco si no lo has hecho antes o no lo has hecho en mucho tiempo. Por lo tanto, es adecuado para estirar el arte de la disciplina, particularmente cuando se ejecuta en programación de pares como lo es generalmente TDD.

En cuanto a enseñarte cosas útiles; Es un ejercicio de una especie de pensamiento lateral. Debe conceptualizar cómo funcionará su código, ejecutarlo, verlo fallar, recopilar datos, refactorizar y continuar iterando. Todas estas cosas son cruciales para TDD. Al vincularlo con el mundo real, es similar a que un cliente le entregue un documento de requisitos impreciso que solo dice "Quiero X". Entonces les das X, pero llegar a X puede ser complicado. Conway's Game of Life es bueno para enseñar eso. También es bastante fácil de codificar y, por lo general, no se necesitan toneladas de código para hacerlo. ( APL es uno de los ejemplos más extremos de implementación). Por lo tanto, es muy adecuado para las sesiones cortas que tendría un retiro en lugar de una semana o dos semanas de iteración, como normalmente se encuentra en un entorno de producción.

Game of Life es, por un lado, un conjunto muy simple de reglas, por otro lado, contiene algunas de las peores advertencias de la programación avanzada, relacionadas con la escalabilidad . Si bien los resultados son deterministas, existe el desafío de un campo de juego infinito y un número infinito de celdas para procesar.

Si las especificaciones del desafío incluyen un rendimiento mínimo y una huella de memoria máxima , entonces las pruebas incluyen patrones de rápido crecimiento o patrones que viajan en varias direcciones a lo largo y ancho, esto puede convertirse en un desafío muy frustrante.

Obtuviste la entrada y salida conocidas después de las iteraciones X, y conoces todos los pasos para llegar allí ... excepto que los pasos toman demasiado y demasiado tiempo. Debe realizar algunas optimizaciones bastante extremas para ajustarse a las especificaciones. El algoritmo trivial con el escaneo de una matriz de bits 2D de doble tamaño y búfer fijo se vuelve totalmente inadecuado a medida que su rendimiento se degrada con O (n ^ 2) del tamaño. Tratar los bloques llenos como nuevos objetos generados de repente consume toneladas de memoria y se vuelve lento. Separar todo en tableros de tamaño limitado a veces funciona, a veces falla ...

Y dado que la mayoría de las pruebas "globales" no cumplirán con el estándar de rendimiento, debe desarrollar objetivos más pequeños, pruebas secundarias más pequeñas que resuelvan las advertencias ...

Todo depende de qué aspecto de tu proceso quieras practicar / entrenar.

Un solo día no es suficiente para cubrir todos los aspectos de la ingeniería de software, independientemente del enfoque / paradigma de gestión de proyectos que elija. Entonces, para que sea efectivo, probablemente debería concentrarse en un pequeño subconjunto del conjunto.

Si se enfoca en los aspectos técnicos de TDD, por ejemplo, es posible que desee dejar de lado las grandes áreas grises en torno a los requisitos y las relaciones con el cliente y pasar directamente a la codificación de una solución.

En este sentido, el Juego de la Vida es un buen candidato porque es simple, bien entendido y no tiene muchas áreas grises en su requisito que estará abierto a debate. Por lo tanto, puede comenzar a escribir su prueba de inmediato y codificar contra ellos.

Si, por otro lado, el objetivo era ver cómo podemos usar TDD para perfeccionar los requisitos, entonces podría haber elegido el juego de la vida, pero no les habría dicho a los desarrolladores que esto es lo que quiero. En cambio, habría dado vueltas dando pistas e ideas sin mencionarlo por su nombre. Dicho esto, el juego de la vida puede resultar un poco demasiado simple para este tipo de ejercicio, ya que los asistentes probablemente verían la estrategia bastante rápido.

Los ejemplos no siempre son fáciles de encontrar para tal ejercicio sintético. tiene que ser simple para hacerse en un día pero no demasiado simple para pasar el día. Tiene que ser divertido pero no sin sentido ... Pero para mí tiene que ser un poco original, no recuerdo cuántas veces me pidieron que hiciera que los estudiantes crearan un sistema de gestión de videoclub para la tarea ... iiirch.