No entraré en detalles de la importancia de esta práctica, creo que ya es sabido y se tienen muy buenos artículos al respecto, pero yendo del dicho al hecho… ¿qué hacemos?

Aquí una lista de consideraciones a tener en cuenta:

1. Roles claros: El código se escribe (autor), se revisa (revisor) y aunque al principio no parezca, le pertenece a todos (dueño). Además, el autor no puede ser juez y parte de lo que propone, el revisor puede incluir a otro revisor en caso de que alguna revisión/observación se extienda más de la cuenta, y como dueños somos responsables de la calidad del código.

2. Reglas claras: Para no depender de opiniones y gustos, debe existir un checklist y este debe ser de conocimiento –y uso– general. Además hay que aceptar que –salvo posibles excepciones– no hay nada nuevo por inventar (estilos, nomenclatura, estructuras, etc.), así que el equipo debe acordar el conjunto de reglas a seguir (existen muchas, con casos ya comprobados), las excepciones del caso y cómo abordar cada una de estas.

3. Tiempos de entrega: El tiempo de revisión, entrega de feedback y correcciones no debe comprometer los avances del trabajo, pero de darse el caso, debemos ser conscientes y empáticos sobre las consecuencias del volumen de código a revisar. En caso de no haberse conversado, volver al punto 2.

4. Esquema de revisión: Se deben abordar aspectos de arquitectura (¿se cumple con la estructura y/o diseño propuesto?), estilos (¿se respetan los estándares de nomenclatura, formato, programación o pruebas?), legilibilidad (¿se entiende sin tener que preguntar al creador?), ubicuidad (¿se usa el lenguaje y terminologías del producto?), funcionalidad (¿cumple con lo requerido?) y cobertura (¿las pruebas automatizadas incluyen los casos no exitosos?). Aquí es importante tener en cuenta que cada uno de estos esquemas de revisión deben reflejarse de manera explícita en las reglas respetadas por el equipo. Caso contrario, volver al punto 2.

5. Feedback concreto, respetuoso y de atención rápida: Siempre hay que tener presente que por más que uno desee, no todos tenemos el mismo nivel de conocimiento y entendimiento, así que para acortar esa brecha, cada observación debe ser lo más clara posible. Incluir código de ejemplo y observar de manera propositiva ayudan mucho, pero ayuda mucho más proponer una sesión de revisión conjunta.

Un abrazo,
JD