6 sencillos consejos para hacer que las requests de incorporación de cambios sean más rápidas de revisar

Una solicitud de extracción permite a los desarrolladores agregar nuevas funciones o corregir errores sin afectar el código principal del proyecto o la experiencia de los usuarios. Pueden escribir y probar actualizaciones de código localmente sin preocuparse por interrumpir el producto en general de esta manera. Entendamos cómo crear mejores requests de extracción a través de 6 sencillos consejos que son los siguientes:

1. Deje que la computadora haga la parte aburrida 

Tu tiempo y energía mental son escasos, no los desperdicies. La revisión del código no debe tratarse de verificar el estilo, las pruebas, las compilaciones o las variables no utilizadas (esto puede sonar obvio para algunos, pero debe saber que no es para todos). Hay 4 acciones que debes automatizar, como verificar:

  • compilaciones de código (con herramientas de integración continua),
  • que pasan las pruebas (con herramientas de integraciones continuas),
  • estilo de código o espacios en blanco (con herramientas de formato de código),
  • variables no utilizadas o importaciones (con linters de código).

Si necesita verificar uno de ellos, encuentre una manera de automatizar esta tarea para la próxima vez.  

2. Habla sobre tu intención

Reconoce que cualquier miembro de tu equipo podría estar leyendo esta solicitud de extracción, incluso si eliges específicamente a tu(s) revisor(es). El contenido y el tono de sus comentarios iniciales deben informarles objetivamente las razones por las que abrió esta solicitud de extracción y cuál es su solución.

Ayuda a los revisores a comenzar su revisión brindando mucho contexto en los comentarios iniciales de problemas o códigos.  

3. Limite el impacto de cada solicitud de extracción en la base de código:

Aplicar el SRP ( principio de responsabilidad única ) a la solicitud de extracción significa que si durante el desarrollo de su solicitud de extracción nota que está creando dos servicios separados (incluso si uno depende del otro), debe abrir una segunda extracción apilada. solicitud además de la primera. De esa manera, reducirá una gran parte de los cambios en dos tareas separadas y ayudará mucho a sus revisores.  

4. Su solicitud de extracción debe hablar por sí misma 

Si está cambiando el frente de cualquier aplicación, hay posibilidades de que esté afectando algo visualmente. Por lo tanto, copie capturas de pantalla en la solicitud de extracción para ayudar a sus revisores.  

¿Es una parte de su código un poco dolorosa de entender? Por lo tanto, debería haber escrito comentarios dedicados dentro del código, pero también puede escribir algunos comentarios de revisión del código antes de que lleguen los revisores. ¡Allanarás el camino para su comprensión!

5. Use una plantilla de solicitud de extracción

Cuando abre una solicitud de extracción en GitHub, puede usar una plantilla de solicitud de extracción para tener un texto preestablecido para su organización. Es muy útil asegurarse de que cada solicitud de extracción siga un proceso uniforme y tener una lista de tareas para que el autor la revise antes de buscar una revisión.

6. Proporcione toda la información necesaria para probar el código

Probar no es divertido, ¿y qué es más frustrante que no saber cómo probar el código de otra persona? Debe proporcionar todos los pasos necesarios para reproducir y probar su solicitud de incorporación de cambios para los revisores. ¿Hay algunos paquetes nuevos para instalar? ¿O un comando específico para comenzar? Detalles completos para operar su código para que su revisor no pierda el tiempo tratando de averiguarlo.

Publicación traducida automáticamente

Artículo escrito por arthur23 y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *