La frase "revisión de código" puede evocar una respuesta negativa para muchos programadores. Esta sensación negativa surge por sentir que se juzgará su trabajo. Los transporta de vuelta a la escuela, al momento del estrés antes de dar un examen. ¿Por qué ocurre esto? Al igual que otras profesiones de la era industrial, los programadores construyen software usando sus manos y su mente. Aunque parezca estructurado, la programación tiene algo de arte. No hay dos individuos que tengan el mismo estilo, y ambos están orgullosos de su trabajo. La pasión es uno de los mayores motivadores del desarrollo de software. Y a la mayoría de las personas les preocupa cómo se juzgará a su trabajo.

Para implementar correctamente una revisión de código y aliviar estas preocupaciones, es bueno explicarle a los equipos sobre los beneficios y su propósito. Veamos entonces lo que son y lo que no son las revisiones de código.

Las revisión de código no son:

  • No son un sistema de ranking o de calificación para los desarrolladores.
  • No tienen ninguna relación con las revisiones de rendimiento.
  • No son el momento para cambiar el estilo de código de alguien.
  • No son el momento para críticas o comentarios negativos.

Las revisiones de código son:

  • Ayudan a compartir y distribuir el conocimiento en el equipo.
  • Ayudan a identificar posibles problemas de lógica o de negocio.
  • Son una excelente forma para aprender trucos y consejos para ambas partes.
  • Son un buen momento para dar feedback constructivo.

Las revisiones de código deberían ser una actividad de equipo donde todos participen. Si permitiemos que cada miembro del equipo sea revisor vamos a fomentar la confianza, la conversación constructiva y la socialización. Y no nos olvidamos que el proceso de aprendizaje es para ambas partes. El revisor también va a aprender algunos consejos de programación. La revisión tiene que hacerse de manera informal. Cuando se termina de escribir el código (o quizás antes), un miembro del equipo podría solicitar una revisión de otro miembro. No hay que apurarse en la revisión. Mostremos el mismo respecto que mostraríamos a nuestro código. El propósito de la revisión es comprender el problema y cómo resolverlo. No es una cacería de brujas para encontrar problemas. Si todo se ve bien, entonces un "parece estar todo perfecto" alcanza. No necesita ser más complicado que eso.

Los resultados de hacer una revisión de código son claros. Con el tiempo aumenta la calidad de código de todo el equipo. También actua como una herramienta de aprendizaje para los desarrolladores juniors o nuevos en el equipo, y brinda un momento de intercambio entre los desarrolladores más experimentados. Incluso con estos beneficios, algunos todavía seguirán teniendolo miedo a la frase "revisión de código". Para eliminar este estigma, algunos desarrolladores prefieren usar la frase "revisión de pares". Y es un cambio positivo, porque refuerza el beneficio al equipo y cambia el foco hacia una codificación responsable en equipo.

Traducido de Code Review: Understanding and breaking the stigma.

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw