Restricciones que podrías aplicar en tus katas

Restricciones de katas que podrías aplicar en algunas katas

Practicar es la mejor forma de aprender, y el desarrollo de código no escapa a esa máxima. Las katas son ejercicios que van a servirte para practicar, y si quieres añadir un plus de dificultad/diversión te proponemos algunas restricciones con las que ir aumentando tu nivel de experiencia a la hora de resolverlas. 

TDD:

🤞Test-and-Commit-or-Revert (TCR)
(Requiere source control) El requisito clave en esta restricción es que los test siempre deben pasar. Cuando la pareja ejecute los test, el código se revertirá automáticamente en caso de que estos fallen. Se puede escribir la cantidad de código que os apetezca, o crear test que tengan simplificaciones que hagan posible que pasen (aunque esos atajos deberían ser de corta duración). Esto difiere del típico ciclo TDD “Rojo-Verde-Refactor”, pero es una buena forma de crear incrementos de código más pequeños y en los que sea más sencillo hacer comprobaciones y poder modificarlos. 

👶 Baby steps
(Requiere source control): Es parecida a TCR, en este caso el objetivo es mantener los test en verde, es decir que todas ellas pasen, pero cada par tiene un temporizador de intervalo configurado en 5 minutos (o puede ser otro intervalo que el grupo/par acuerde). Durante ese tiempo, escriben un test y el código para aprobarlo. Si el código de test es verde cuando acaba el tiempo confirman el código. Si los test no pasan, entonces se debe volver al código al último test verde (eliminando los últimos 5 minutos de trabajo). Las parejas también pueden elegir usar el intervalo para refactorizar, pero se aplica la misma regla: Si falla al refactorizar requiere una reversión. Lo que conseguimos es crear el incentivo de realizar cambios más pequeños e incrementales en el código.

👩‍⚖️ TDD As If You Meant It
Todo el código debe escribirse solamente en el test. La única forma de crear código de producción es mediante la refactorización (via Extract Method/Class/Field/Variable, etc). Esto da como resultado un código de producción mínimo y muy ajustado.

Respecto a TDD te recomendamos que te descargues nuestro ebook sobre antipatrones que seguro que puede serte de utilidad. 

CODE

🙅 Sin declaraciones condicionales
No se permiten declaraciones if/switch/ while/loop. Vas a poder explorar el control de decisiones a través del polimorfismo, estructuras de búsqueda (matrices de control, tablas hash), comprensión de listas, etc. La decisión sobre aliviar esta restricción cuando se esté practicando (permitir loops, por ejemplo) queda a discreción del facilitador de la sesión. 

🙅 Ninguna otra declaración
Consiste en reemplazar Nested Conditional por Guard Clauses

🦖 Sin primitivos
Todos los métodos (excepto los constructores) deben tomar clases como argumentos. No estarán permitidos números enteros, cadenas, etc. Si quieres un nivel más avanzado trata de evitar primitivas como valores de retorno, con lo que vas a conseguir que los métodos de prueba de predicados sean más desafiantes.

IDE

🖱 Sin mouse
No puedes usar el mouse, aunque es posible que tengas usarlo al principio para descubrir los atajos del teclado que son correctos. 

📚 Solo editor de texto
No vas a poder utilizar un entorno integrado, sólo podrás usar un editor de texto sencillo y un compilador de línea de comandos. Esto ayuda a exponer cuánto sabes realmente sobre la sintaxis de tu lenguaje y puede resaltar cómo las características del IDE aceleran el desarrollo (resaltado de sintaxis, autocompletado, refactorización, etc.)

PAIR PROGRAMMING 

Más detalles sobre pair programming: fundamentos y aspectos clave a tener en cuenta. 

🚦Conductor y navegante

Estas definiciones clásicas de roles de programación de pares se pueden aplicar de una forma u otra a muchos de los enfoques de emparejamiento. El conductor es la persona que controla el teclado. Está concentrada en completar el objetivo que tiene entre manos, ignorando los problemas más importantes por el momento. Es importante que comparta con el compañero lo que está haciendo mientras lo hace. El navegador tiene rol de observador, mientras el conductor escribe; revisa el código, da instrucciones y comparte ideas. El navegador también está atento a los problemas y errores más importantes, y toma notas de los posibles próximos pasos u obstáculos.

⏱ Strong-Style Pairing

La persona en el teclado (conductor) escribe el código, y la persona que no está frente al teclado (navegador) toma todas las decisiones de diseño del código. Es el navegador quién indica al conductor las instrucciones con el nivel más alto de abstracción con el que el conductor sea capaz de trabajar de manera fluída. El conductor y el navegador cambian sus roles cada X tiempo (acordado) por ejemplo cada 2 a 5 minutos hasta completar el código par que pase el test.

🏓 Ping-Pong

Esta técnica se basa en Test-Driven Development (TDD) y es perfecta cuando tienes una tarea claramente definida que se puede implementar basándose en test.

Ping: la persona A escribe una test que da fallos.
Pong: la persona B escribe la implementación necesaria para que pase el test
La persona B inicia el siguiente "Ping", es decir, el siguiente test fallido.
Y así sucesivamente, 

En cada Pong también se puede seguir refactorizando el código juntos antes de pasar al siguiente test fallido; esta es la forma en la que mantendremos el enfoque "Rojo - Verde - Refactor". Escribe un test que falla (rojo), haces lo necesario que pase con los medios mínimos necesarios (verde) y luego refactor.

👥 Mob programming

Grupo de tres o más personas, con roles alternos de conductor y navegante. Quien no es conductor ni navegante será  quien haga las sugerencias de estrategias para resolver los problemas que encuentren y responderá las preguntas del navegador.

🔇 Mute Ping-Pong

Muy parecido a Ping-Pong, pero una de las personas solo escribirá test y la otra solo escribirá el código para pasar la prueba. La pareja no puede discutir ni comunicarse sobre el problema de ninguna otra manera que no sea a través del código. Quien habla es el código. 

😈 Evil Coder (aka codifica con tu "enemigo" y  encuentra la salida (utilizando Ping-Pong)

El controlador es el "enemigo": implementará el código que hace que pase el test, pero puede introducir tanta complejidad en el código como desee o elegir una estrategia de implementación algo "oscura". El Evil Coder combinado con Mute Ping-Pong es una práctica para desarrolladores avanzados, pero puede ser extremadamente divertida si te apetece subir el nivel. 

Te dejamos este enlace con más restricciones diseñadas para ayudarte a pensar en escribir código de manera diferente a como lo harías habitualmente de otra manera.