Revisa código como un experto

Una de las responsabilidades que empiezas a asumir cuando te vas convirtiendo en desarrollador senior es revisar el código de tu equipo. 

Una revisión del código es un documento escrito que busca mejorar el código y la calidad del trabajo del equipo. Es un proceso que consiste en dar retroalimentación y sugerencias de mejora sobre el código antes de que se fusione y se despliegue en producción. 

Te conviertes en un mejor desarrollador cuando notas la importancia de una buena revisión y más aún si la haces tú mismo. 

Aprende 4 consejos para revisar código como todo un experto:

1. Empieza ¡YA!

Ten las revisiones de código como prioridad. Cuando leas el código y des tu opinión, tómate tu tiempo, pero empieza a hacerlas apenas te den la tarea. 

Si un compañero pide tu revisión, probablemente significa que está bloqueado hasta que se la entregues. Seguro se te vino a la mente “para eso usamos Git (o cualquier source control system)”, pero seamos honestos, muy pocos desarrolladores pueden fusionar los cambios de la revisión a una nueva rama de manera eficiente. 

El plazo máximo de una ronda de revisión debería ser un día laborable. Si estás luchando con un problema de alta prioridad y no puedes completar una revisión en menos de un día, házselo saber a tu compañero de equipo y dale la oportunidad de reasignarlo a otra persona. Si te ves obligado a rechazar revisiones más de una vez al mes, probablemente significa que tu equipo necesita reducir su ritmo para poder mantener unas prácticas de desarrollo sanas.

2. Critica al código, no al autor 

Es crucial que durante la revisión del código, seas amable, respetuoso y, a la vez, muy claro y útil para el autor. Intenta empezar con algo positivo, apreciando a los autores al encontrar algo que hayan hecho bien.

Las críticas deben ser concisas y estar escritas en un lenguaje neutral. Cuando algo no esté claro, pide una aclaración en lugar de asumir su ignorancia. Evita los pronombres posesivos, sobre todo en combinación con las evaluaciones, como por ejemplo: "tu código tiene un error". Evita los juicios absolutos, como por ejemplo: "esto jamás va a funcionar".

Siempre que tu comentario sugiera un enfoque alternativo, es crucial explicar por qué y proporcionar un ejemplo basado en tus conocimientos y experiencia, para ayudar al desarrollador a entender cómo tu sugerencia va a ayudar a mejorar la calidad del código.

Cuando sugieras correcciones o cambios, encuentra el equilibrio adecuado sobre cómo guiar al autor para que arregle el código. Por ejemplo, brindarle la orientación, la explicación y algunos consejos o sugerencias, y nunca la solución completa.

Cuando termines de revisar el código, indica hasta qué punto esperas que el autor responda a tus comentarios y si te gustaría volver a revisarlo después de que se hayan implementado los cambios. 

3. Prioriza

Mientras más comentarios escribas en una revisión, más te arriesgas a que el autor se sienta abrumado. El límite exacto varía según el desarrollador, pero la zona de peligro suele comenzar en el rango de 20-50 comentarios en una sola revisión.

Limítate a hacer comentarios de “alto nivel” en las primeras revisiones. Céntrate en cuestiones como el rediseño de la interfaz de una clase o la división de funciones complejas. Espera a que se resuelvan esos problemas antes de abordar cuestiones de “menor nivel”, como la denominación de las variables o la claridad de los comentarios del código.

Los comentarios menos importantes podrían ser discutidos una vez que el autor haya hecho los cambios más importantes. Al aplazarlos para una revisión posterior, te ahorras el trabajo y evitas que el autor procese comentarios innecesarios. Esta técnica también dirige tu atención durante la revisión, ayudándote a ti y al autor a trabajar de una manera clara y sistemática.

4. ¡Que la máquina trabaje!

Leer el código de un compañero de equipo es un esfuerzo cognitivo y requiere un alto nivel de concentración. No malgastes estos recursos en tareas que puede hacer la computadora, especialmente cuando ésta puede hacerlas mejor.

Los errores de espacio en blanco son un ejemplo obvio. Compara el esfuerzo de un revisor humano al encontrar un error de sangría y trabajar con el autor para corregirlo, frente al uso de una herramienta automatizada.

La automatización te ayuda a hacer contribuciones más significativas como revisor. Cuando puedes ignorar toda una clase de problemas, como el orden de las importaciones o las convenciones de nomenclatura para los nombres de los archivos fuente, te permite centrarte en cosas más interesantes como los errores funcionales o las debilidades en la legibilidad.

La automatización también beneficia al autor. Le permite descubrir errores por descuido en segundos en lugar de horas. El feedback instantáneo hace que sea más fácil aprender de ellos y más simple corregirlos porque el autor sigue teniendo el contexto relevante en su cabeza. Además, si tienen que escuchar que cometieron un error tonto, es mucho más fácil para su ego si lo escuchan de una computadora en lugar de ti.

Solo para dar un ejemplo, si necesitas verificar que los espacios en blanco del código coinciden con el estilo del equipo puedes utilizar un formateador de código, como ClangFormat (formateador de C/C++) o gofmt (formateador de Go).

¡Te toca a ti! 

Nadie puede darte una receta para una revisión perfecta. Las técnicas que mejor funcionan dependen de la personalidad del autor del código, de tu relación con él y de la cultura de tu equipo. 

Recuerda que las revisiones de código existen para asegurarse de que el código no tenga errores, bugs o problemas, que cumpla con todos los requisitos, normas de calidad y guía de estilo, que haga lo que debe hacer y que cuando se fusione, la base de código esté en su mejor estado. 

En un mundo ideal, el autor del código estaría agradecido por cada revisión que recibe. Es una oportunidad para aprender y los protege de los errores. Sin embargo, en la realidad, hay una serie de factores externos que podrían hacer que el autor percibiera la revisión de forma negativa y se resintiera a los cambios. Tal vez esté presionado para cumplir un plazo, por lo que cualquier cosa que no sea tu aprobación instantánea se siente como un obstáculo. Tal vez no hayan trabajado mucho juntos, por lo que no confía en que tus comentarios sean bienintencionados. 

La mejor recomendación para que tus comentarios sean bien recibidos es que pienses en que detrás del código hay un humano con sentimientos. ¿Le dirías lo que estás escribiendo directamente a la cara?