Xuaps

Código fuente

Revisiones de código

Lo he dicho mil veces, por aquí y por allí, “enfócate en la calidad”, “la calidad no es negociable”… pero reconozco que es más fácil decirlo que hacerlo. Los compromisos, las prisas, el cansancio son factores que nos hacen flaquear y escribir código del que no estaremos muy orgullosos.

En Refly ha pasado, pasa y seguirá pasando. Una de las mejores técnicas que hemos encontrado para resolver este problema, sin tener en cuenta la programación en parejas (aunque está relacionado), han sido las revisiones de código.

No hacemos revisiones de código formales, hacemos revisiones de código ligeras, principalmente por preferencias personales pero también porque en un equipo de dos personas con un flujo de comunicación constante parece una sobrecarga el tema de las revisiones formales. En cualquier caso, al principio no las incluimos en nuestro flujo de trabajo normal y lo estamos pagando. También las dejamos atrás después de hacer varios cambios en el equipo y tampoco fue una buena idea. Nos ha quedado claro, por las malas, que las necesitamos.

Podemos hablar de cómo hacerlas, herramientas, cómo comunicar los problemas encontrados… todos temas muy interesantes que, si os interesa, trataremos en otros post. En esta ocasión os voy a hablar de cómo las introdujimos en nuestro flujo normal de trabajo.

Para simplificar diré que usamos Trello para organizar el trabajo, si os interesa tambien puedo ampliar más este tema en otro post. Lo primero que hicimos fue crear una columna en Trello después de la columna doing llamada code-review y a hacer una “rama por historia” en git. Probamos varias herramientas, Gerrit, Barkeep, “PullRequest” y nos quedamos con ReviewBoard. Esta última te permite generar y publicar un patch en el servidor para que alguien te lo revise. El caso es que a pesar de ser una buena herramienta nos generaba una sobrecarga. Teníamos que andar entre Trello y ReviewBoard y a veces las tarjetas no se mantenían sincronizadas adecuadamente. Así que decidimos prescindir de ReviewBoard y subir directamente los patchs a Trello. En el otro extremo alguien los baja, lo aplica y los revisa.

generar patch -> git format-patch branch –stdout > mipatch.patch
aplicar patch -> git am mipatch.patch

Todos los comentarios quedan en la tarjeta de la historia y la comunicación tiene lugar por un único canal. ¿Es demasiado sencillo? Pues funciona sin demasiados problemas. Algunas veces hemos tenido algunos para aplicar o generar un patch pero creedme era culpa nuestra no de la herramienta. Y eso es todo, creo que las revisiones de código nos han ayudado a ser un mejor equipo, a mejorar la calidad del producto y a dormir mejor por las noches.

¿Y tú que piensas?

Han salido un montón de temas interesantes, programación en parejas, cómo hacemos en Refly revisiones de código, qué herramientas usamos, metodología. Si para ti también lo son, por favor alúmbrame el camino, comenta o envíame un mail diciéndome cuál te interesa más y tu opinión sobre lo que te he contado aquí.

Hasta entonces, revisa tu código.