Haga comentarios cortos.
Es difícil mantenerse concentrado, especialmente durante la revisión del código, durante mucho tiempo. Además, las revisiones largas de código pueden indicar que hay mucho que decir sobre el código (ver los siguientes dos puntos) o que la revisión se convierte en una discusión sobre temas más importantes, como la arquitectura.
Además, una revisión debe seguir siendo una revisión, no una discusión. No significa que el autor del código no pueda responder, pero no debería convertirse en un largo intercambio de opiniones.
Evite revisar el código que es demasiado malo.
Revisar el código de baja calidad es deprimente tanto para el revisor como para el autor del código. Si un fragmento de código es terrible, una revisión de código no es útil. En cambio, se le debe pedir al autor que reescriba el código correctamente.
Use verificadores automáticos antes de la revisión.
Los verificadores automáticos evitan perder tiempo valioso señalando errores que se pueden encontrar automáticamente. Por ejemplo, para el código C #, ejecutar StyleCop, las métricas de código y especialmente el análisis de código es una buena oportunidad para encontrar algunos de los errores antes de la revisión. Luego, la revisión del código puede gastarse en puntos que son extremadamente difíciles de hacer para una máquina.
Elija cuidadosamente a las personas que hacen comentarios.
Dos personas que no pueden soportar el uno al otro no harán una buena revisión del código de otro. El mismo problema surge cuando una persona no respeta a la otra (no importa si es el revisor o el autor, por cierto).
Además, algunas personas simplemente no pueden ver su código revisado, por lo que requieren capacitación y preparación específicas para comprender que no son criticadas y que no deberían verlo como algo negativo. Hacer una revisión, sin preparación, no ayudará, ya que siempre estarán a la defensiva y no escucharán ninguna crítica de su código (tomando cada sugerencia como crítica).
Haz revisiones tanto informales como formales.
Tener una lista de verificación ayuda a concentrarse en un conjunto preciso de fallas, evitando que se convierta en la selección de liendres. Esta lista de verificación puede contener puntos como:
- Inyección SQL,
- Suposiciones erróneas sobre un lenguaje que puede conducir a errores,
- Situaciones específicas que pueden conducir a errores, como la precedencia del operador. Por ejemplo, en C #,
var a = b ?? 0 + c ?? 0;podría verse bien para alguien que quiera agregar dos números anulables con fusión en cero, pero no lo es.
- Desasignación de memoria,
- Carga diferida (con sus dos riesgos: cargar la misma cosa más de una vez y no cargarla en absoluto),
- Desbordamientos,
- Estructuras de datos (con errores como una lista simple en lugar de un conjunto hash, por ejemplo),
- Validación de entrada y programación defensiva en general,
- Hilo de seguridad,
- etc.
Dejo la lista aquí, pero hay cientos de puntos que pueden figurar en una lista de verificación, dependiendo de los puntos débiles de un autor preciso.
Ajuste progresivamente la lista de verificación.
Para mantenerse constructivo y útil a lo largo del tiempo, las listas de verificación utilizadas en las revisiones formales deben ajustarse con el tiempo dependiendo de los errores encontrados. Por ejemplo, las primeras revisiones informales pueden revelar una cierta cantidad de riesgos de inyección SQL. La comprobación de inyección SQL se incluirá en la lista de verificación. Cuando, unos meses después, parece que el autor ahora tiene mucho cuidado con las consultas dinámicas frente a las parametrizadas, la inyección SQL puede eliminarse de la lista de verificación.