💃 ♠️ ✊🏿 Revisión de código: mejora del proceso 👩🏼‍🚀 👩🏻‍🤝‍👨🏿 🏨

Imagine un equipo donde no se realiza la revisión del Código. Los desarrolladores escriben código y, sin verificarlo, realizan todos los cambios en la rama principal. Después de un tiempo, la funcionalidad se expande o se encuentran errores, regresan al código original, y allí todas las variables se nombran con una letra, no hay seguimiento de la arquitectura y la calidad no es la mejor. Este código de baja calidad se acumulará y algún día llegará el momento en que, con poca innovación, el proyecto comenzará a desmoronarse: en el mejor de los casos, el tiempo de desarrollo aumentará, en el peor, el apoyo del proyecto será imposible. Y esto a pesar del hecho de que una vez la tarea se completó y todo funcionó bien.

¿Cómo puede esto ser evitado?La respuesta a la pregunta en el título es Revisión de código.

La revisión de código es una verificación de código para errores que mejora la estabilidad y la calidad del código.

Ahora imagine un equipo donde la revisión del Código ya está en marcha, pero en el proceso que los desarrolladores juran entre sí, la solicitud de extracción no se aprobó por mucho tiempo, las tareas comienzan a congelarse. El proceso desde el comienzo de la tarea hasta su aparición en el proyecto se alarga, y con él todo el trabajo se ralentiza.

La solicitud de extracción / solicitud de fusión es una solicitud al equipo del proyecto (persona o grupo de personas) para su aprobación y aplicación de cambios a la sucursal seleccionada. Tan pronto como se crea la solicitud de extracción, se realiza una discusión del código escrito antes de la aprobación. Se pueden sugerir cambios durante la discusión. Después de la aprobación, los cambios actuales caen en la rama seleccionada.

A continuación se enumeran recomendaciones para ayudar a acelerar la revisión del Código y mejorar su calidad.

Dividimos la pregunta en tres partes y las consideramos por separado:

Parte técnica: ¿cómo verificar el código y qué buscar al verificar?
Parte de comunicación: ¿cómo prevenir disputas y reducir el estrés durante la discusión?
Parte organizativa: ¿qué se puede hacer para que el proceso de revisión del Código sea eficiente?

Parte 1. Verificando el código

Ejecuta el código del autor en casa

Ejecute el código por su cuenta y vea cómo funcionan los cambios junto con el resto del código. Esto ayuda a encontrar áreas problemáticas que no son visibles en la interfaz basada en web. Intente ver el código exhaustivamente, evite centrarse solo en los cambios locales. Entonces descubrirá rápidamente el código y encontrará rápidamente imprecisiones arquitectónicas, si las hay.

Recuerda la experiencia del usuario

Preste atención a cómo los cambios en el código afectarán al usuario final. Incluso el código más bellamente escrito puede ser inútil para los usuarios, lo que generará tareas adicionales, errores y también puede golpear la reputación de la empresa y el producto.

Nos fijamos en la lógica general

Los desarrolladores pueden resolver con éxito su problema, pero interrumpen el trabajo de otras piezas de código. Para evitar que esto suceda, observe no solo cómo se resuelve una tarea específica, sino también cómo los cambios afectarán el trabajo de otros servicios, módulos y todo el proyecto en su conjunto.

Nos fijamos en la arquitectura del código.

La arquitectura del código determina cuánto tiempo en el futuro dedicaremos a expandir, agregar funcionalidad o editar un error. Además, la arquitectura del código puede afectar la posible aparición de errores en caso de cambios en el proyecto. Idealmente, expandir y agregar nueva funcionalidad no debería conducir a una refactorización.

Escribimos más fácil

Preste atención a la nueva complicación del código: cuanto más simple es el código, más fácil es de leer y más fácil de mantener. Deshágase de piezas complejas de código.

Multithreading

Si el proyecto implica trabajar en varios subprocesos, vea qué sucede si hay un retraso durante la ejecución del código en uno de los subprocesos y cómo se resuelven estos casos.

Optimización excesiva

Como escribió el clásico Donald Knuth, la optimización prematura es la raíz de todo mal. Es mejor optimizar solo lo que se necesita aquí y ahora.

Resolvemos errores

Preste atención a cómo se comportará el proyecto si no fuera posible ejecutar una línea de código, un bloque de código o una solicitud al servidor. A menudo, los desarrolladores interrumpen la ejecución de una función sin salida de error, pero estos casos deben resolverse.

Conformidad

El código debe cumplir con el acuerdo, el estilo del código. La uniformidad del código no es un capricho, sino una necesidad: dicho código es más fácil de mantener y es más fácil de entender.

Nombres y apariencia

Recuerde a otros programadores que tendrán que entender su código. El código legible simplifica su soporte adicional. Los nombres deben ser comprensibles y describir con precisión la clase, el objeto, la función, etc.

Comentarios de código

Los comentarios deben responder a la pregunta: "¿por qué se hace esto?", Y no "¿cómo se hace esto?". Recuerda esto.

Parte 2. Discutimos

La regla principal de discusión: cualquier comentario debe estar dirigido al código y no a la persona que lo escribió. Funciona en la dirección opuesta: no tome los comentarios como una crítica personal. La tarea de la revisión de código es mejorar su código, porque lo que no ha notado puede ser notado por otros. Los colegas pueden proponer soluciones alternativas, y este es el potencial para el crecimiento profesional. Es importante recordar que la discusión del código no es un concurso de ingenio o una muestra de "quién sabe más", por lo tanto, el sarcasmo, la agresión oculta y la grosería son inapropiados.

Como regla general, la solicitud de extracción se realiza en un alojamiento web especial (github.com, bitbucket.org, gitlab.com, etc.), donde es posible ver los cambios y dejar un comentario en un código específico.

Cumplimos con el acuerdo

Nuevamente, el código debe cumplir con el acuerdo. Sin embargo, si dicho acuerdo no existe, no debe pedirle a un colega que agregue un espacio o sangría en el código.
En momentos controvertidos, puede estar de acuerdo con todo el equipo en el proceso de revisión del código, pero pedir seguir estas reglas es mejor en la siguiente revisión del código, por lo que será más fácil para todos aceptarlas. Por cierto, una directriz documentada en el estilo de escritura elimina casi todas las disputas.

Ofrecemos una alternativa

Evite declaraciones como "Hiciste mal ...", "¿Por qué, por qué escribes así?" y otros, son percibidos como críticas y conducen a excusas. Es mejor escribir un comentario sobre el contenido del código, sin recurrir a la identidad del autor. También trate de evitar órdenes y coacciones: a las personas no les gusta cuando alguien las ordena y perciben tales comentarios negativamente.

Puede proceder de la siguiente manera:

Escribimos lo que está mal con el código
¿Por qué es mejor no escribir?
Ofrecemos opciones alternativas

Nos mantenemos en el marco del problema.

A menudo puede ver comentarios sobre el código que estaba antes y que no tocó. No es necesario comentar sobre lo que no es relevante para la tarea. Las ediciones de terceros pueden llevar mucho tiempo y pueden percibirse negativamente, por lo que es mejor observar cómo una persona completó la tarea actual y no pedirle que refactorice el proyecto.

Alabanza

Si ve una solución interesante o genial, no dude en alabar. Además, es una gran motivación para sus colegas continuar escribiendo un buen código en el futuro.

Todos los comentarios son iguales.

A menudo sucede que un programador técnicamente sabe más que el otro, como lo demuestra la gradación de líder de equipo junior, medio, senior. No vale la pena destacar los comentarios de un grupo como más importantes. Esto devalúa la opinión de algunos desarrolladores, lo que puede generar indiferencia y participación formal en la revisión del código. Cuando las opiniones de todos son igualmente importantes, la revisión del código es más productiva.

Expresa claramente tus pensamientos

Para una comunicación productiva, escriba lo más detallado posible y explique cada detalle. Todos tienen un nivel de conocimiento diferente, y hasta ahora nadie ha aprendido a leer las mentes.

Haciendo preguntas

No dude en preguntar a sus colegas por qué su opción propuesta es mejor que la actual. Esta es una gran oportunidad para aprender algo nuevo y crecer profesionalmente.

Resolvemos conflictos

Sucede que una persona no acepta todos los argumentos y no puede ofrecer los suyos, se niega a hacer algo. Algunos consejos prácticos para este caso:

La mayoría de las situaciones de conflicto se pueden resolver hablando en persona, en un tono amigable.
Puedes conceder, ya que no puedes escribir código mientras estás en guerra.
Puede atraer a todo el equipo y decidir juntos la mejor forma de escribir el código.
En la revisión actual del código, deje todo como está y haga que los temas controvertidos separen las tareas para refactorizarlas, es decir, las tareas, porque las palabras "luego arreglarlo", como regla, nunca cobran vida.

Parte 3. Mejorando el proceso

Describimos lo que hicieron.

Describimos la esencia de la tarea en el encabezado de la solicitud de extracción (o hacemos un comentario por separado) y qué pasos se han tomado para completarla.

Divida la solicitud de extracción en partes

Se observará una gran parte durante mucho tiempo, se discutirá durante mucho tiempo y se corregirá durante mucho tiempo. Divida el código en pequeñas partes lógicas, de esta manera el proceso irá mucho más rápido.

Responder a todos los comentarios

Es aconsejable responder a cada comentario para que el equipo no tenga ambigüedades. Otros desarrolladores deben entender que leyó su comentario, hizo el trabajo necesario e hizo correcciones. Abrir constantemente una solicitud de extracción y ver lo que se ha solucionado y lo que no es muy inconveniente y requiere mucho tiempo.

¿Busca todo?

Hay diferentes enfoques: buscar el máximo de lo posible o primero comentar momentos arquitectónicos importantes y, después de la corrección, prestar atención a las pequeñas cosas.
Ambos métodos tienen derecho a la vida. Creo que la segunda opción lleva más tiempo: imagina que después de la corrección necesitas revisar completamente el código nuevamente, comentar y esperar las correcciones nuevamente. Es mucho más rápido revisar cuidadosamente el código una vez, dejar comentarios y luego verificar las correcciones.
Si hay imprecisiones arquitectónicas y está claro que los errores menores desaparecerán después de arreglar la arquitectura, no debe perder el tiempo comentando los detalles en esta sección del código.

¿Esperando a todos?

No puede esperar hasta que todos aprueben la solicitud de extracción y acepte que la aprobación del 80% de los revisores es suficiente para cerrar la tarea. Esto acelerará la entrada del código en la rama principal, lo que sin duda es más beneficioso para los procesos comerciales, pero puede generar desacuerdos en el equipo e indiferencia a la revisión del código.

La segunda opción es esperar la aprobación de todos los desarrolladores involucrados. La calidad del código aumentará, pero el proceso en sí mismo se ralentizará significativamente. La elección a favor de la velocidad o la calidad, cada equipo debe hacer lo suyo.

Cosas Pequeñas

Si no hay comentarios serios sobre el código, entonces no necesita esperar hasta que se eliminen todas las pequeñas inexactitudes. Pueden indicarse en los comentarios y aprobar de inmediato la solicitud de extracción: el autor del código se sentirá más tranquilo, su lealtad al equipo aumentará, sentirá que es de confianza. Y, por supuesto, la velocidad de solicitud de extracción aumentará.

Conclusión

La revisión del código es una parte importante del proceso de desarrollo, que afecta al proyecto en su conjunto, por lo que es peligroso ignorarlo. Algunas de estas recomendaciones ayudarán a acelerar la revisión del código, algunas de ellas lo mejorarán. Espero que mi experiencia y conocimiento sean útiles para los lectores de este artículo.

Revisión de código: mejora del proceso