Partiendo de que repetir una y otra vez este tipo de problemas no tiene el mismo valor que resolver problemas reales (no acotados), sí que tiene sus usos.
Uno de esos usos es colaborar en mejorar las katas (mediante peer review).
¿Qué?
La idea es simple: Estudiar la kata de otra persona.
Si encuentras defectos, crea y comparte con el autor los casos de prueba necesarios para demostrarlo (quizá con algún refactoring para hacer el código más testable). De esta forma el autor puede corregirlos y tú volver a revisarlos, iniciando una especie de diálogo.
Elegir de quién vamos a aprender
Lo primero es elegir una implementación de las que han sido publicadas en el github de 12meses12katas
Después tendremos que localizar el fork del autor. Con un poco de suerte, su usuario en github será el mismo del directorio y el proyecto se llamará igual que en 12meses12katas.
En mi caso, mi carpeta es amuino, por lo que mi url será:
https://github.com/amuino/Enero-String-Calculator.git
Si esto no funciona para localizar el fork, habrá que mirar la red del proyecto.
Preparar nuestra copia
Queremos enviar nuestros casos de prueba al autor de la kata, así que tendremos que configurar nuestro clon del repositorio para apuntar al clon del autor de la kata (de forma que trabajemos todos con el mismo código).
Mi opción para ello es crear una rama que siga al repositorio del autor:
git remote add -f -m master amuino https://github.com/amuino/Enero-String-Calculator.git
git checkout -b amuino amuino/master
Ya está, nuestro repositorio local tienes una rama amuino
que sigue a mi repositorio. Además, estás usando esa rama.
(cambia amuino
por el nombre del usuario que corresponda)
Enero-String-Calculator $ git branch
* amuino
master
Cuando necesitemos volver a seguir nuestro repositorio, simplemente cambiamos a la rama master: git checkout master
Escribir los casos de prueba
Nada especial aquí… excepto, tal vez, que deberemos aprender lo básico del lenguaje en el que se haya hecho la kata para poder escribirlo y ejecutarlo (si es uno en el que no tengamos soltura).
Commit & Push
Tampoco hay nada especial en el commit.
git add .
git commit -m "Test para XYZ"
En el push, hay que recordar indicarle a git que debe crear una rama remota:
git push origin amuino
Desde este momento podremos ver la rama en nuestro proyecto de github.
Pull request
Todos los pasos se hacen en la web tu fork en github
Primero, cambia a la nueva rama (en mi caso, yo he usado la kata de Jorge Uriarte).
A continuación, iniciamos una pull-request. Por defecto, estará preparada para enviarla al repositorio de 12meses12katas:master
. Haciendo click podemos cambiarlo seleccionando cualquiera de los forks. Hay que localizar el que nos interesa (si es el mío: amuino/Enero-String-Calculator
).
Para confirmar el cambio, pulsamos el botón Update Commit Range.
Y ahora continuamos con el proceso normal de escribir un título y una descripción para la pull-request.
¡Listo!
El autor recibirá su notificación y podrá ponerse en contacto con vosotros si lo necesita para discutir el problema o aceptar el pull y mejorar su kata (o pasar de todo, que siempre es una opción).
¿Te mola la idea?
¡Pues no necesitas pedir permiso!
Puedes usar twitter para solicitar reviews o discutir la idea usando el tag #katabreakers
Otras opciones
Hay más formas de hacer lo mismo. Puedes usar parches y adjuntarlos a una issue en github, puedes hacer code reviews sobre los commits…
Si te gustan más, úsalas. Lo interesante es que aprendas del trabajo de otro y le ayudes a eso otro a aprender del tuyo.
Happy breaking!