Revisar todo antes de salir

Revisar, revisar, revisar... Qué tarea tan complicada. Al hacer un examen escrito revisar es una de las recomendaciones que más nos hacen nuestros maestros y con justa razón, pues a pesar de que sepas hacer todo el procedimiento de manera correcta un sólo error de dedo te puede llevar a reprobar el examen si tus resultados no son los correctos. Cuando uno está dado los primeros pasos en la creación de software esto no es tan dramático pues a pesar de que se cuenta con una limitación de tiempo el resultado a nivel de usuario pocas veces se ve afectado si no revisamos nuestro código, pero espera... ¿Me estás diciendo que no debería de refactorizar mi código? Va a ser que no, pero para que te enteres de lo que realmente te estoy tratando de decir, te invito a seguir leyendo.

Revisando y aplaudiendo

via GIPHY

Revisar código no se limita a ir a revisar función por función a ver si no cometiste un error de nuevo que esté haciendo que tu producto no esté funcionando de la manera adecuada sino que también involucra que no haya errores de seguridad o errores de arquitectura que te hagan perder tiempo, dinero y sobre todo clientes. Si no revisas todos estos parámetros cuando estás implementando nuevas funcionalidades a tu sistema terminarás con un producto con un riesgo muy alto de que algo vaya mal. 

¿Qué hay cuando hay miembros de sexto semestre en tu equipo de trabajo que piensan que saben todo en la vida? Bueno, no te desesperes, algún día fuiste así de petulante y lo que te toca hacer es enseñarle buenas prácticas con el fin de que su eficacia aumente y también ellos a la larga te ayuden a encontrar errores a primera vista. En este punto quizá estés pensando que es absolutamente inaceptable que un newbie ponga siquiera una línea de código en algo que tu estás trabajando, pues al final, ¿quién conoce mejor tu código que tu mismo? Si piensas de manera similar déjame decirte que estás en un error ya que, el que alguien externo venga y revise algo que tu has implementado te da un feedback excelente y el que tu también lo hagas con un compañero tuyo aumenta sus habilidades de manera impresionante al comunicarse entre sí y compartir buenas prácticas.

F de Fagan

via GIPHY

Como siempre, la fiesta iba del todo bien en el mundo de los errores hasta que llegó Michael Fagan no, no hablo del mismo que se coló a la habitación de Isabel II, pues en 1970 su técnica era muy utilizada como el proceso para encontrar defectos en documentos de desarrollo, hasta le pusieron su nombre a la técnica y todo quedó como la Inspección de Fagan. Todo ha evolucionado hasta nuestros días y aunque su técnica no es utilizada masivamente, sí contamos con varias herramientas que nos pueden ayudar a limpiar nuestro código de posibles errores tales como:

1. Gerrit: Código abierto y construido sobre el control de versiones de git, la verdad es que es un must si usas GitHub.
2. Review Assistant: Se trata de una extensión de Visual Studio y soporta controles de versiones dadas por TFS, Subversion, Git y otra cantidad insana más. 
3. Crucible: Hecho por Atlassian, esta opción te permitirá revisar y comentar el código y colaborar fácilmente con todo tu equipo, ¿lo mejor? Que Jira también es de Atlassian y también Bitbucket así que lo tendrás muy bien si eres fan de la compañía.

Otras opciones que quizá quieras revisar son: UpSource por JetBrains, Collaboration y Parasoft.

via GIPHY

Si no eres tan de utilizar herramientas o plugins adicionales al IDE que ya usas también puedes utilizar técnicas presenciales aunque desde ya, si vas a hacer algo formal no te lo recomiendo mucho.

1. Over–the–shoulder: como su nombre lo dice, esta técnica consta de tener alguien constantemente atrás de ti revisando el código de manera rápida y a ojo de pájaro, no es muy recomendable más que para hacer un feedback rápido.
2. Pair programming: dos cabezas siempre serán mejor que una y los programadores saben eso así que optaron por poner a dos personas en una sola PC mientras programaban. Si esto no abre las puertas del infierno en tu oficina puede servir para crear software de calidad.
3. Email pass around: pasar código a través de correo electrónico para que alguien lo revise... ¿Suena mal? Pues hacerlo es peor.

Recuerda que la revisión del código no se hace hasta el final, esto se debe de hacer desde las etapas tempranas para que tu software no incremente su riesgo. Sea cual sea la técnica que uses, asegúrate siempre de producir buen software, ¡hasta la próxima!