¿Qué contiene una revisión de código estándar?

En mi empresa, es una discusión por correo electrónico de qué función se implementa y qué tipo de error se corrige enviado por quien escribe el código. Y el revisor, que recibe el correo, revisará el código y discutirá la calidad y cómo editar el código en su opinión. ¿Qué contiene una revisión de código estándar?

En mi experiencia, la mayoría de las revisiones formales de códigos se convierten en verificación de estilo porque es fácil. Incluso cuando proporciona una lista de verificación de las cosas para mirar, es bastante fácil para los ojos comenzar a glasear.

Descubrí que la revisión de la prueba unitaria brinda más beneficios. La mayoría de los desarrolladores con los que he trabajado realmente no saben cómo realizar pruebas unitarias correctamente, y una vez que obtienen ese "¡Ajá!" momento el resto de su código comienza a mejorar también. Aquí hay una pista: no es una prueba unitaria si requiere que el usuario inspeccione algo, y no es una prueba unitaria si solo está comenzando algo para ejecutarse en un depurador.

Tiende a variar según cuál sea el problema. Muchas veces es un simple sello de goma. "Esto es lo que era el problema, mira esta línea aquí, es obvio lo que está mal, y aquí es donde lo arreglé". "Sí, eso es bastante obvio. Adelante, échale un vistazo".

Pero cuando sucede algo más complicado, generalmente es así:

• Ejecute Buscar modificaciones en TortoiseSVN y obtenga una lista de los archivos modificados.
• Traiga al revisor a su oficina.
• Explique el problema, con el CR del sistema de seguimiento de errores abierto como referencia.
• Baje la lista de archivos en TortoiseSVN, abriendo cada uno de ellos en BeyondCompare para ver los cambios.
• Si el revisor no comprende los cambios, explique lo que hizo y por qué.
• El revisor puede notar algo que no se ve bien. Si es así, discútalo hasta llegar a un acuerdo sobre si se debe cambiar o no. (Si es necesario realizar cambios simples, incluso puede editar el archivo dentro de BeyondCompare).
• Si ha realizado algún cambio, vuelva a compilar y asegúrese de que se compila.
• Ejecute el programa para demostrar al revisor que su solución realmente funciona.
• Compruébalo

En mi opinión, una revisión de código no tiene nada que ver con características o errores, pero se centra en la calidad del código y las pruebas escritas para él.

Entonces, te sientas al lado de tu compañero y le pides que te explique el código, o toma el código y lo revisa, sea cual sea la situación.

Ayuda cuando todos programan con los mismos estándares y si empleas herramientas como fxCop para automatizar parte del proceso.

Prefiero la revisión del código donde el desarrollador se sienta con el revisor y revisa el código línea por línea para explicarlo. A menudo, el desarrollador verá un problema al hacer la explicación que el revisor puede no haber visto todavía, razón por la cual esta es mi preferencia. También hago revisiones de código donde me envían el código y lo leo por mi cuenta y hago comentarios, pero encuentro que tienden a tomar más tiempo (reviso y redacto comentarios y los envío al desarrollador que los lee y se va WTF, ¿ella quiere decir y correos electrónicos? me devuelvo y explico y dos o tres rondas después nos juntamos y señalo en la pantalla a qué me refiero y el desarrollador dice: "oh sí, ahora lo veo") y ser menos productivo ya que hay menos discusión genuina y más, "Hiciste esto mal".

También es crítico hacer cumplir los estándares en una revisión de código, pero no hacerlos el único enfoque.

Sin embargo, el código no se envía a producción hasta que el revisor del código esté contento o el gerente (no el desarrollador) lo haya anulado (los revisores del código también se han equivocado). Esto es crítico o la revisión de código es solo un proceso burocrático sin valor agregado a menos que el revisor de código deba aprobar el código final antes de que se envíe.

Primero necesita tener estándares de codificación y estos son más que simples sintaxis. Cuando las personas comienzan en su empresa, deben aprender las pautas de su empresa tanto como sea posible antes de comenzar a codificar . Si en el proceso de revisión se encuentran todo tipo de violaciones, lo más probable es que:

• no se arregla debido a limitaciones de tiempo
• resultó ser más molesto de lo que valen las pautas

Las pautas deben tener sentido y debe haber herramientas adecuadas para encontrar infracciones y refactorizar lo más fácil posible. Siempre mire el objetivo de las pautas y la revisión del código

El objetivo en mi mente es hacer que el código sea lo más uniforme posible y encontrar problemas de mantenimiento y legibilidad. Un objetivo secundario puede ser poner al día a más personas con una determinada pieza de software.

Las pautas en mi mente podrían, por ejemplo, existir de:

• sintaxis general y pautas de codificación (elija una que ya exista y use herramientas que verifiquen automáticamente)
• Manejo adecuado de excepciones
• Registro adecuado
• Buen uso de los paradigmas para el lenguaje (SOLID para lenguajes OO)
• Dependencias obvias y bien pensadas entre componentes (use herramientas como NDepend)
• Script de compilación de trabajo
• Documentación presente (inicio del desarrollador, manual de instalación)
• bibliotecas internas para usar
• Compañía de Policías
• herramientas de terceros que no están permitidas
• Pruebas unitarias presentes y sin fallas
• cobertura de código del 90%
• ...

Con eso en su lugar, la revisión del código consiste en que el software se verifique con las pautas y:

• discutir violaciones con el programador
• arreglar violaciones innecesarias
• comentar las violaciones necesarias