[vc_row][vc_column][vc_column_text]
Introducción
Cuando se trata de revisión de código, todo depende de la empresa y del modo de trabajo del equipo, o del proceso que convierte una idea en un producto de software.
Con este artículo, se presenta una alternativa para la revisión de código, la cual representa un proceso que muchos adoptan. Primero describiremos el proceso y luego los examinaremos con más detalle.
Un supuesto es que, las revisiones de código se realizan contra código que se envían con pruebas, independiente a la forma de desarrollo (pruebas primero, pruebas al final, … ).
En resumen, los pasos son los siguientes:
- Verifiquen si existen las pruebas
- Asegurarse de que todas las pruebas pasen
- Validar que las pruebas cumplan con los criterios de aceptación
- Validar que las pruebas están escritas correctamente
- Verifique el código para sugerencia de mejoras (código más limpio, mejor estructura, cuellos de botella en el rendimiento, partes no utilizadas, etc.).
- Proporcionar comentarios al equipo utilizando las herramientas disponibles
Ahora revisaremos cada uno en detalle.[/vc_column_text][/vc_column][vc_column][vc_single_image image=»1699″ img_size=»full» alignment=»center»][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Verificar que existan las pruebas
Este es el paso más básico y una sugerencia sería no avanzar con la revisión de un determinado código si este no tiene pruebas relacionadas. Una simple razón detrás de esto es que el desarrollador no esta seguro de que el código hace lo que tiene que hacer, y sin esta mínima garantía no hay forma de revisar el código.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Asegurarse de que todas las pruebas pasen
Ahora que verifico que existen las pruebas, puede ejecutarlas y asegurarse de que ninguna falle. Esto previene que los colegas envíen código con errores, pruebas con errores o código con problemas de regresión.
En caso de que tenga CI/CD (Integración Continua/Despliegue Continuo), este proceso debe incluir las pruebas y este proceso (si esta configurado adecuadamente) debe cubrir otro tipo de pruebas.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Validar que las pruebas cumplan los criterios de aceptación
El tercer paso es básicamente un resumen de los criterios de aceptación y las pruebas disponibles. Obvio, esto depende del proceso (compañía, equipo), entonces, si utilizas un proceso del tipo BDD es más fácil de verificar que se cubren todos los casos.
De hecho, este paso asume que se han leído de forma cuidadosa los criterios de aceptación y tiene una idea de que escenarios esta cubriendo.
La comunicación es la llave en todas las fases del desarrollo, por lo tanto, se encontrará haciendo preguntas a los colegas del equipo, a la gente de negocio, a los dueños del producto para asegurarse de que lo que esta escrito en los criterios de aceptación es lo mismo que se validen en las pruebas.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Validar que las pruebas están escritas correctamente
Imagina que todos los pasos previos están correctos pero luego nota que las pruebas, tal como están escritas, no validan nada, o la configuración es equivocada, o no se ha realizado alguna validación. Algunas veces la configuración del código (mocks o configuración de BD u otros) es muy engorrosa que incluso deba revisar que los datos de prueba son válidos primero antes de verificar los asserts más adelante.
En esta fase, se encontrará profundizando en el código y evaluándolo, no solo la forma en que se configuran las pruebas sino también un poco de la implementación. Lo que eventualmente lo llevará a alternar entre este paso y el último.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Verifique el código para sugerencia de mejoras
Mientras revisa las pruebas (especialmente las pruebas del tipo BDD) empezará a revisar muy profundo en el código. En este momento empezará a tomar notas sobre el algoritmo, estructura de código, código limpio, partes no utilizadas, posibles cuellos de botella y otras recomendaciones.
Puedes mirar dentro de las pruebas de usuario y validar de nuevo los criterios de aceptación.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Proporcionar comentarios al equipo utilizando las herramientas disponibles
Este es el paso final del proceso que estamos revisando, ahora que ha evaluado todo y está listo para proporcionar comentarios. Algunas cosas pueden suceder en esta fase:
- Esta contento con todo, aprueba todo y mueve la tarea a hecho.
- Escribe algunos comentarios menores. Dependiendo de las herramientas disponibles puede realizar la discusión directamente con los colegas o agregar determinados comentarios en la herramienta de colaboración.
- Esta sugiriendo cambios mayores. En este caso, la comunicación es la llave, discute los cambios con los colegas, asegurarse de que esta seguro sobre las suposiciones, y el cambio requiere ser realizado, y luego puede entrar en implementación de acuerdo con el proceso acordado. Esto podría ser programación de pares, usted hace el cambio, su colega hace el cambio; todo depende del proceso acordado.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Conclusión
Esta es sólo una forma de hacer revisión de pares y esto asume muchas cosas. Por favor, escribir, si tiene comentarios, discutir diferentes perspectivas y tal vez encontrar mejoras y probarlas.
Este código se encuentra basado en One Way of Doing Code Reviews[/vc_column_text][/vc_column][/vc_row]
