Abel Muiño

home

#katabreakers: Peer review de 12meses12katas

30 Jan 2011

12meses12katas es una idea muy interesante para poner a disposición de todo el mundo (para escarnio o inspiración) soluciones a problemas muy acotados.

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.

<I will find the droids I'm looking for I will find the droids I'm looking for I will find the droids I'm looking for

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).

Cambio de rama en github

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!