¿Por qué hacer revisiones de código?

Los equipos de desarrollo de muchas organizaciones han adoptado las revisiones de código como una de sus prácticas básicas. Aunque parece algo muy razonable, con el paso del tiempo el objetivo que condujo a la adopción de esta práctica se olvida y lo único que queda es la aplicación sin sentido de la práctica en sí.

¿Por qué necesitamos revisiones de código?

Mantener la calidad. Difundir conocimientos. Evitar errores graves en la producción. Mantener la coherencia en el diseño y la arquitectura del software. Todas ellas respuestas muy convincentes y lógicas, sin duda, pero si esos son los objetivos, ¿es la revisión del código la forma más eficaz de alcanzarlos?

Es difícil hablar de una práctica como la revisión de código sin conocer mejor el contexto en el que se aplica. Para ello puedes responder a ciertas preguntas como:

• ¿Con qué frecuencia se realiza?
• ¿Antes o después de fusionar el código?
• ¿Cuántas personas participan?
• ¿Cuál es el tamaño del equipo?
• ¿Hay equipos distribuidos?
• ¿Cuál es el tamaño medio del código que se revisa? ¿Un par de clases con unas pocas líneas cada una o unas pocas clases con cientos de líneas cada una? 
• ¿El código sólo está relacionado con una pequeña parte del dominio o afecta a múltiples áreas de su aplicación?
• ¿Tienen las personas el poder de rechazar el código que se está revisando? ¿Cuántas personas tienen este poder? ¿Líderes de equipo? ¿Los arquitectos? ¿Todo el equipo, incluidos los desarrolladores junior?
• ¿Qué ocurre cuando se rechaza el código? ¿La base de código la modifican desarrolladores de la misma organización o se trata de un proyecto de código abierto que puede aceptar contribuciones de desarrolladores de todo el mundo, que no se conocen entre sí y tienen poca responsabilidad sobre sus cambios?
• ¿Qué se busca en una revisión del código? ¿Encontrar errores? ¿Falta de coherencia? ¿Pequeños detalles como nombres de variables? ¿Grandes violaciones de la arquitectura? ¿Cumplimiento de requisitos no funcionales? ¿Mal diseño?
• ¿Está de acuerdo el equipo en lo que significa un mal/buen diseño?

Conocer las respuestas a estas preguntas es extremadamente importante para decidir si la revisión de código (y cómo se hace) es realmente la mejor manera de alcanzar nuestros objetivos.

Revisiones de código complicadas

Bueno, la revisión de código es una práctica y no puedes culparla si el código que se está revisando es un desastre. Tampoco si decidiste revisar una gran parte del código semanas después de que se fusionara. Es la forma en que decidiste hacer las revisiones de código lo que puede ser complicado, no la práctica en sí.

¿Cuándo y por qué utilizar revisiones de código?

• Antes de que se fusione a producción: Trabajar haciendo pairing y en pequeñas ramas de muy corta duración (aproximadamente 2 horas de codificación y muy pocas clases cambiadas). Las parejas hacen pull requests (una media de 2 a 5 al día) y otra pareja revisa su código. Como trabajamos en incrementos muy pequeños, las revisiones, aunque frecuentes, son muy fáciles y rápidas de hacer. El código rara vez se rechaza y, cuando lo hace, es muy fácil y rápido de arreglar. De este modo evitamos tener que volver a trabajar mucho y disminuimos las posibilidades de acumular deuda técnica.
  
  

• Difundir conocimientos y evitar trabajo innecesario: Tener a miembros del equipo 'paireando' y revisando el código de otras parejas, ayuda a difundir el conocimiento de las distintas partes del sistema y también evita que determinados miembros del equipo hagan trabajo innecesario.

• Revisión de código durante un proceso de entrevista: El código no miente. Los CVs sí. En la primera fase de nuestro proceso de entrevistas, pedimos a los candidatos que envíen un código. Después lo revisamos y les damos una respuesta exhaustiva. Esta es nuestra oportunidad para evaluar exactamente dónde están los candidatos en términos de sus habilidades básicas como desarrolladores.
  
  
• Capacitación de aprendices: Nuestros craftspersons revisan regularmente todas las katas y pet projects desarrollados por sus aprendices. Consideramos que las revisiones de código son una técnica de enseñanza muy valiosa, ya que los aprendices primero intentan resolver los ejercicios lo mejor que pueden y luego se les muestran mejores formas de hacerlo, si las hay.
  
  
• Revisar diferentes enfoques y experimentar: A veces no nos ponemos de acuerdo fácilmente en cómo debe escribirse un fragmento de código. Cuando eso ocurre, normalmente trabajamos un poco aislados para experimentar y luego hacemos que el resto del equipo revise el código. Es más fácil debatir sobre algo concreto que mantener conversaciones hipotéticas con interminables preguntas.

¿Cuándo no utilizar las revisiones de código?

• Para verificar si hay bugs: Esto me parece inútil. Tenemos tests para ello. El código sólo se revisa cuando se han superado todas las pruebas. No obstante, los tests forman parte de la revisión de código.

• Después de que el código se fusiona a producción: Es demasiado tarde. ¿Qué hacemos si descubrimos que el código no es lo suficientemente bueno? Si el código ya está escrito, funciona, está en producción y no se va a cambiar pronto, ¿por qué revisarlo y cambiarlo? Yo esperaría a cambiarlo si alguna vez tengo que trabajar en él.

• Cuando el código es demasiado grande: Revisar cambios grandes es cansado e irrespetuoso. En mi última empresa, decidimos en equipo rechazar los cambios grandes. Los desarrolladores/as tendría que dividir ese cambio en cambios más pequeños y confirmarlos poco a poco para que el evaluador pudiera darle sentido. Sólo se revisarían y fusionarían en producción los cambios pequeños. 

• Revisar los estándares de código: Normalmente utilizo Java y tenemos un montón de herramientas de análisis estático que se ejecutan durante nuestras construcciones. Si el código no cumple el mínimo de calidad definido (por el equipo) en estas herramientas, la compilación falla. No se revisa el código si falla la compilación de la rama.

Hay otras situaciones en las que utilizaría o no revisiones de código, pero esas son las más importantes.

¿Por qué usar pair programming para las revisiones de código?

Hacer pair programming para las revisiones de código nos proporciona un bucle de retroalimentación mucho más rápido y ayuda a minimizar los errores. Según nuestra experiencia, el código escrito por desarrolladores/as haciendo pairing tiene muchas más posibilidades de ser aceptado en una revisión de código que cuando lo escribe una sola persona.

Las revisiones de código son rápidas y baratas de hacer cuando se trabaja en pequeños incrementos, en parejas y rotando constantemente las parejas. Como los conocimientos técnicos y de dominio se extienden rápidamente por todo el equipo, las revisiones de código se convierten más en un mecanismo de intercambio de conocimientos que en un control de calidad.

Conclusión

Muchos problemas durante las revisiones de código pueden evitarse cuando tenemos una buena cultura de equipo. Las prácticas sin objetivos no tienen sentido. Antes de elegir una práctica, averigua exactamente qué quieres conseguir y sólo entonces elige prácticas que te ayuden a conseguirlo. Las prácticas no pueden adoptarse a ciegas. Para que funcionen, hay que tener el contexto y la mentalidad adecuados. De lo contrario, corres el riesgo de culpar a las prácticas de tus propias deficiencias.