Alguien en mi comunidad de me preguntó acerca de mejorar en la revisión de las solicitudes de extracción (PR) hoy, lo que motivó esta publicación. Con suerte, encontrará algo útil aquí. ¡Me encantaría saber de ti si lo haces! Y si no lo hace, también está bien. ¡Sugerencias para mejorar mi proceso son bienvenidas! Virtual Coffee Primero, leo el título y la descripción para ver de qué se trata todo esto. Si hay problemas u otras relaciones públicas a las que se hace referencia, las reviso si necesito más contexto. Si hay cambios en la interfaz de usuario (UI), busco capturas de pantalla antes y después. Si no hay capturas de pantalla y hay cambios en la interfaz de usuario, le pido al revisor que incluya algunos. Hace que sea mucho más fácil evaluar los cambios desde un vistazo de alto nivel. ¡Bien! ¡Ejecutemos el código para probar esto! Vaya, todavía no. A continuación, empiezo a hojear todos los archivos modificados. Si hay muchos cambios en los archivos, la revisión de relaciones públicas puede volverse intimidante y difícil de manejar. En general, los PR deben ser pequeños por un par de razones: Es más fácil revisar Cuantos menos cambios tenga en el código, menor será el potencial de errores. Digo potencial porque incluso una sola línea puede causar errores. A veces no hay más remedio que tener un PR significativamente grande. He visto esto principalmente en el trabajo de interfaz de usuario, pero también se aplica al trabajo de back-end, generalmente un escenario de todo o nada. Si lo anterior no se cumple, estas son las razones por las que veo que las relaciones públicas se inflan: La persona detecta refactorizaciones o correcciones de errores que puede hacer, pero no están relacionadas con las relaciones públicas. Pídales que los coloquen en un RP separado y mantengan el RP para la tarea en cuestión. El trabajo a realizar no se desglosa. Haz un trabajo que haga avanzar el trabajo más extenso. Por ejemplo, una función de utilidad utilizada en toda la característica puede estar en un PR separado. ¿La persona está creando una nueva interfaz de usuario? Pueden construir los componentes de forma independiente y colocar un PR diferente, potencialmente usando una herramienta como para construirlos. Storybook Recuerde que no es necesario asignar un problema o característica a un PR. ¡Finalmente, miro algo de código! Busco problemas que me llamen la atención sin bajar el PR y ejecutar el código en mi local. No estoy hablando de problemas de formato/estilo de codificación porque hoy en día, muchos proyectos tienen herramientas como linters o formateadores de código. Cosas que busco: errores lógicos una característica del idioma que la persona podría no conocer y que se puede usar en el RP aprovechar las funciones de utilidad existentes en el código base pruebas documentación problemas de accesibilidad En algunos casos, el estilo de codificación puede surgir, por ejemplo, regresando temprano cuando falla una condición en una función o método. Si surgen cambios durante una revisión que se pueden cambiar automáticamente, ¡automáticamente! Sin embargo, haz eso en un PR separado. 😎 Después del primer barrido del código, devuelvo el PR al revisado si tengo solicitudes de cambio. ¿Espera un segundo? ¿Todavía no has ejecutado el código? Como revisor, también tengo trabajo que hacer, así que me abstendré de tomar el PR para una prueba de manejo. Después de la revisión inicial, compruebo los cambios realizados y los comentarios. Puedo proporcionar más comentarios. Una vez que no quedan cambios (por el momento), bajo el código y lo ejecuto localmente. Según la configuración del proyecto, es posible que tenga implementaciones de vista previa para relaciones públicas en un host como Netlify o Vercel o algún entorno en contenedores para probar. Independientemente, ahora es el momento de verificar las intenciones del RP. En este punto, lo más probable es que aún haya comentarios de revisión, por lo que continúo el ciclo de revisión de los cambios y me aseguro de las intenciones del RP. Dependiendo del trabajo, el proceso de revisión puede llevar algún tiempo; las diferencias de zona horaria pueden exacerbar el tiempo de revisión. Es fundamental , especialmente ahora que gran parte de la industria tecnológica se está mudando o se ha mudado a una cultura remota. volverse excelente en la comunicación asíncrona Por último, el tono de una revisión es importante. Me he acostumbrado a usar un marco para comentar llamado . Si está interesado en obtener más información, di una el año pasado. Netlify creó un sistema similar llamado . Comentarios convencionales charla relámpago sobre los comentarios convencionales Feedback Ladders Si llegaste hasta aquí, ¡tu PR está aprobado! 😎 ¡Gracias y hasta la próxima! Foto de en Markus Winkler Unsplash También publicado aquí: https://www.iamdeveloper.com/posts/how-i-review-pull-requests-44nl/
