Odiame a mi, pero no al código

“Esto no sirve, esta horrible...”, te suena familiar?

Probablemente más de una vez lo has pensado, hecho o recibido dentro de un code review donde lo que se busca es criticar, señalar y enfatizar en las cosas que podrían mejorarse, y perdiendo de vista lo que realmente importa.

Y no es la unica frase, que me dices de:

“Este código no tiene pies y cabeza, como le digo que no sirve”

Y es que en ocasiones no es fácil expresar una opinión imparcial sobre algo que no sigue lo que tu consideras buenas prácticas, haciendo que el código apenas si se pueda leer. Pero, detente a pensar, como te gustaría que te vieran tus compañeros de trabajo? Es común tratar de evitar los conflictos y ser esa persona que a todos cae bien por que siempre le da `LGTM` a su código, ese que siempre invitan a las fiestas, no importando que después tengas que andar apagando fuegos en las noches o los fines de semana, por que se ocupaba enviar algo rápido y no había tiempo para revisar ni probar.

No está mal rechazar un Pull Request

Aun mejor, porque no estar en un punto intermedio donde puedes ayudar a los demás con su código para que no tenga tantos errores, seguir convenciones y no poner en peligro la amistad, interesado? Aun cuando eso implique dedicar parte de tu tiempo a hacer su trabajo ya sea corrigiendolo, opinando o enseñando?

Tal vez una mejor alternativa seria hacer uso de herramientas que nos faciliten el adoptar mejores practicas al programar, a realizar mejor su trabajo, también una técnica muy conocida y muy efectiva es hacer pair programing para explicar a alguien algo que le está costando trabajo.

Incluso atacar la raíz del problema, los Code Reviews, si ves algo que no tiene pies y cabeza, abre una discusión, nadie tiene la verdad absoluta descubre el razonamiento detrás de la solución, sugiere mejores condiciones siempre explicando claramente las ventajas y desventajas para que se corrija (para eso también sirven los code reviews), es una estupenda oportunidad para enseñar y aprender al mismo tiempo.

“Esta es una manera de resolver parte del problema, mira basados en esto….. Por qué no probamos algo como esto….”

Suena mejor, verdad?

Predicar con el ejemplo

Empezemos por el código

Cuando empiezas en un proyecto es buena practica dictar las reglas básicas de como se va a trabajar, que tan largas deben ser las lineas, la indentación, número máximo de lineas por método entre otras, con dichas reglas, debería de ser fácil seguirlas, dejando de ver su mal uso dentro de PR, sin embargo, viejos hábitos mueren lento, cuantas veces haz visto que te dan ganas de llorar, lineas de mas de 80 caracteres, tabs en lugar de espacios, mala identación, aun cuando ya se establecieron las reglas.

Un PR no se trata de revisar gramática, hay mejores formas de invertir tu tiempo, una forma de evitar seguir viendo y rechazando PR que no siguen las reglas, es el uso de herramientas que te ayudan a revisar y dictar dichas reglas, herramientas que evalúan la sintaxis y estilo del código antes de realizar un commit o incluso antes de enviar tus cambios, siendo fácil evaluar si la regla se cumple, en caso de no hacerlo que no te permita continuar hasta que hayas corregido, herramientas como rubocop si trabajas con ruby o deepcode si trabajas con javascript, solo debes buscar una que se ajuste al lenguaje que estas usando.

Y ahora nuestros Pull Request

Existen diferentes herramientas/mecanismos para mejorar la colaboración en los Pull Request, si usas github, puedes generar templates para especificar cómo debe ser un Pull Request, o acaso nunca te haz topado con un PR que no tiene descripción, o que su descripción es solo el título del ticket en el mejor de los casos, careciendo completamente de contexto que ayude al que revisa el código a entender el porque de la solución.

Una forma fácil de no caer en esta trampa es la de asegurarse que los Pull Request respondan a estas preguntas:

  • Por qué se creó el pull request?
  • Que era lo que faltaba si es un nuevo feature?
  • Qué es lo que fallaba si es un fix?
  • Una descripción breve, sin explicar el código, de como se soluciono
  • Como debe probarse?
  • Si es que se necesitan, indicar procedimientos adicionales como correr migraciones o agregar variables y los valores para probar

Parece una lista muy larga, y mucho trabajo adicional, pero créeme no lo es, las ventajas son enormes, no deberías aceptar un PR que no responde estas preguntas por el simple hecho de no saber que se resolvió y porque.

Si lo sé, dejaras de ser la persona mas querida, que es invitada a todas las fiestas, probablemente algunas personas dejaran de saludarte con el entusiasmo que solían tener, pero es la responsabilidad que todos deben de tener al trabajar colectivamente, y eventualmente se convertirá en una forma de trabajar que les facilitara el trabajo a todos.



Ulices Barajas


comments powered by Disqus

Siguenos

Boletí de noticias