Las revisiones de código analfabetas ralentizan seriamente el flujo de trabajo. Cuando una gran cantidad de cambios se atascan durante unos días (¡o semanas!), Entonces el lanzamiento del producto en el mercado tendrá que posponerse. Aquí hay algunas razones por las que esto sucede:

No hay un diseño de código estándar.
No se utilizan controles automáticos
Los programadores no analizan independientemente su código.
Enormes solicitudes de piscina
Solicitudes vagas de piscinas
Faltan fechas límite para la revisión del código

No hay un diseño de código estándar.

Cada equipo debe adoptar un estándar de formato de código (estándar de programación, guía de estilo), con el que todos estén de acuerdo. Incluye convenciones de nomenclatura, estructura de carpetas, formato de código y una lista de mejores prácticas, como pruebas unitarias, validación, etc.

La falta de un estándar claro y convenciones obliga a cada desarrollador a escribir el código que desee, lo que lleva a disputas de código. -revisión. Si ve muchos comentarios sobre formato, convenciones de nombres y más, entonces es hora de hablar sobre un estándar común.

Su equipo puede desarrollar su propio conjunto de recomendaciones o comenzar con recomendaciones bien conocidas de otras compañías. Aquí hay un ejemplo de Google .

No se utilizan controles automáticos

Después de adoptar estándares de código, aprenda las herramientas para verificar el cumplimiento de estos estándares. Para casi todos los idiomas, existen herramientas para formatear código, linters y otras utilidades que puede poner en ganchos antes de comprometerse y registrarse en los sistemas CI / CD.

Estas herramientas verifican que el código cumpla con los estándares de diseño y notifican al autor las violaciones. El autor tiene la oportunidad de solucionar problemas antes de enviar una solicitud de grupo, lo que reduce significativamente el ruido. Cuantas más comprobaciones se aprueben automáticamente, más tiempo tendrá el revisor para centrarse en problemas más serios, como fallas en la arquitectura, brechas de implementación, etc.

Los programadores no analizan independientemente su código.

Antes de contactar a sus colegas para una revisión de código, el autor debe revisar sus propios cambios. Es como verificar el texto de una carta en busca de errores tipográficos y errores antes de enviarlo al destinatario.

En la práctica, validar su propio código es un desafío porque tiende a omitir inconscientemente fallas. Aquí hay algunas formas de mejorar la calidad del autoanálisis:

Haga una solicitud de grupo sin designar revisores y vuelva a consultarla después de un par de horas para revisar sus ediciones.
Suprima su tendencia natural a cambiar los cambios y, en su lugar, mírelos intencionalmente línea por línea.
Siga la lista de verificación: ¿Cumple el código con el estándar de diseño? ¿Se cumplen todos los requisitos comerciales? ¿Hay alguna prueba para todos los casos de uso posibles? etc.

Enormes solicitudes de piscina

El número de comentarios a la solicitud de grupo es inversamente proporcional al número de cambios que contiene. Es decir, un gran PR → pocos comentarios, un pequeño PR → muchos comentarios.

El hecho es que los revisores no estudian cuidadosamente la solicitud de grupo grande, sino que tienden a desplazarse a través de ella para completar el trabajo más rápido. Esto va en contra del propósito de una revisión de código. A veces sucede lo contrario cuando el autor no recibe ningún comentario durante muchos días, porque el revisor teme comenzar a revisar demasiadas relaciones públicas.

Divida la solicitud de la agrupación en piezas más pequeñas que tengan sentido por separado una de la otra. Entonces ayudará a considerarlos de manera adecuada y rápida.

Solicitudes vagas de piscinas

A menudo se le ofrece una solicitud de grupo con una descripción vaga o sin ninguna. El revisor debe comprender el significado de los cambios, tratando de recordar la tarea que se discutió en algún lugar de la reunión o en el rastreador de errores. Por lo tanto, es mejor proporcionar a los RP información de apoyo:

¿Qué cambios contiene?
Con qué archivos comenzar
Enlace a la tarea en el rastreador de errores
Capturas de pantalla si esto es algún tipo de cambio visual

Esta información proporcionará un mejor contexto para el revisor y, por lo tanto, acelerará la revisión del código.

Faltan fechas límite para la revisión del código

Una forma de extender la revisión del código para siempre es no establecer plazos para el revisor. Defina plazos razonables, por ejemplo:

El código de revisión debe completarse dentro de las 48 horas posteriores al envío de la solicitud del grupo.
Para las revisiones, el período es de 30 minutos.

¡Gracias por leer! :)

Cómo acelerar la revisión de código