¿Cómo hacer mejores revisiones de código cuando las solicitudes de extracción son grandes?

12

Descargo de responsabilidad: Hay algunas preguntas similares, pero no encontré ninguna que toque específicamente los problemas a los que se enfrenta al revisar una gran solicitud de extracción.

Problema

Siento que las revisiones de mi código se podrían hacer de una mejor manera. En particular, estoy hablando de revisiones de códigos grandes con muchos cambios en más de 20 archivos.

Es bastante simple detectar problemas obvios de código local. Sin embargo, comprender si el código cumple con los criterios comerciales es una historia diferente.

Tengo problemas para seguir el proceso de pensamiento del autor del código. Es bastante difícil cuando los cambios son numerosos y se reparten en varios archivos. Intento concentrarme en los grupos de archivos relacionados con una pieza particular de cambios. Luego repasa los grupos uno por uno. Desafortunadamente, la herramienta que uso (Atlassian Bitbucket) no es muy útil. Cada vez que visito un archivo, se marca como visto, aunque a menudo resulta que no está relacionado con la pieza de cambios examinada actualmente. Sin mencionar que algunos archivos deben visitarse varias veces y sus cambios deben revisarse pieza por pieza. También volver a los archivos relevantes cuando sigues una ruta incorrecta no es fácil.

Posibles soluciones y por qué no funcionan para mí

La revisión de una solicitud de extracción mediante confirmaciones a menudo resuelve los problemas de tamaño, pero no me gusta ya que con frecuencia estaré viendo cambios obsoletos.

Por supuesto, crear solicitudes de extracción más pequeñas parece ser un remedio, pero es lo que es, a veces se obtiene una solicitud de extracción grande y se debe revisar.

También puede ignorar el aspecto lógico del código en su totalidad, pero parece bastante arriesgado, especialmente cuando el código proviene de un programador inexperto.

Utilizar una mejor herramienta podría ser útil, pero no encontré una.

Preguntas

  • ¿Tiene problemas similares con las revisiones de su código? ¿Cómo los enfrentas?
  • ¿Quizás tienes mejores herramientas?
pregunta Andrzej Gis 11.11.2018 - 22:30

4 respuestas

7

Tuvimos estos problemas y hacer la siguiente pregunta nos ha funcionado bien:

¿El RP hace una cosa que se puede fusionar y se puede probar de forma independiente?

Intentamos romper las relaciones públicas por responsabilidad única (SR). Después de la reacción inicial, la gente se sorprendió al encontrar que incluso algo pequeño aunque sencillo puede ser grande.

El SR hace que sea realmente fácil de revisar y también difunde el conocimiento de la implementación esperada.

Esto también permite refactores incrementales a medida que se agregan más y el tiempo de respuesta de PR se reduce drásticamente.

Si es posible, sugeriría dividirlas por SR y ver si funciona para ti. Toma algo de práctica para hacerlo de esa manera.

    
respondido por el PhD 12.11.2018 - 03:11
11

A veces no puedes evitar las grandes solicitudes de extracción, pero puedes discernir quién tiene qué responsabilidad.

Trato las solicitudes de extracción como argumentos persuasivos. El autor está tratando de convencerme de que el código debería verse y funcionar de esta manera.

Como con cualquier argumento, debe tener una sola idea clara. Es cualquiera:

  • un refactor,
  • una optimización,
  • o nueva funcionalidad.

Si no están siendo claros, entonces hay una buena posibilidad de que ellos mismos no lo entiendan. Abre el diálogo y ayúdalos a dividir su argumento en sus sub-argumentos. Si es necesario, está perfectamente bien, incluso es beneficioso para ellos recrear esos compromisos y ofrecer solicitudes de extracción más comprensibles y directas.

Todavía habrá grandes solicitudes de extracción, pero con un argumento claro es mucho más fácil ver lo que no encaja.

En cuanto a las herramientas, depende de su organización y proceso. BitBucket es una herramienta decente, ya sea que sea mejor o no, depende de todo, desde su presupuesto, hardware, requisitos, hasta sus procesos preexistentes, reglas comerciales y diversas adaptaciones de software que ya haya hecho para adaptarse a BitBucket. Comenzaría mirando la documentación para ver si se puede configurar el comportamiento, tal vez eliminando a la comunidad de complementos (o uniéndome a ellos haciendo un complemento para hacer eso).

    
respondido por el Kain0_0 12.11.2018 - 00:04
8

No revise la solicitud de extracción completa, sino cada confirmación. De todos modos, obtendrás una mejor comprensión de la solicitud de extracción al hacerlo de esta manera.¹

Si las confirmaciones son pequeñas, realizar dicha revisión no debería ser un problema. Sigues los cambios uno por uno a través de los cambios y terminas obteniendo la imagen completa. Existen inconvenientes, como el hecho de que a veces revisará los cambios que se desharán unos pocos intentos más adelante, pero esto no debería ser un gran problema.

Si las confirmaciones son grandes, debe discutirlas con la persona que las realizó. Explíquele por qué los grandes cometidos son problemáticos. Escuche los argumentos de la otra persona acerca de por qué él comete cambios raramente: puede aprender, por ejemplo, que evita hacer compromisos porque los enganches de pre-confirmación toman demasiado tiempo, en cuyo caso este problema debería resolverse primero.

  

La revisión de una solicitud de extracción mediante confirmaciones a menudo resuelve los problemas de tamaño, pero no me gusta ya que con frecuencia estaré viendo cambios obsoletos.

Sí, pero este es un problema menor, y debería perder mucho menos tiempo revisando el código, el cual se deshará unas cuantas confirmaciones más tarde que el tiempo que perdió tratando de averiguar por qué se cambió el código al revisar un solo archivo.

"Con frecuencia" es impreciso, pero si pasa demasiado tiempo revisando el código que no llegó a la revisión final de la solicitud de extracción, puede utilizar dos técnicas:

  • Ir rápidamente a través de todos los compromisos una vez, solo leyendo los mensajes de confirmación. De esta manera, cuando estudie una confirmación en particular, puede recordar que un mensaje de confirmación en alguna parte dijo que el cambio que estaba viendo fue revertido.

  • Tenga una vista en paralelo de la última versión del archivo (aunque en muchos casos, para grandes confirmaciones, (1) los archivos pueden ser radicalmente diferentes y (2) los archivos pueden cambiar de nombre o los grandes bloques de código pueden moverse a otra parte, lo que dificulta la búsqueda del archivo coincidente).

  • Pídales a los comensales que aplasten las confirmaciones cuando tenga sentido, o tenga una convención específica de mensajes de confirmación donde una confirmación deshaga una parte de otra, y realice su revisión teniendo en cuenta varias confirmaciones siguientes.

¹ Por ejemplo, imagina que estás viendo un archivo donde se ha cambiado el nombre de alguna variable. ¿Qué te dice? ¿Cómo deberías revisar este cambio? Sin embargo, si estuviera revisando la confirmación por confirmación, vería que una única confirmación cambió el nombre de la misma variable en veinte archivos, y el comentario indica que se cambió el nombre para utilizar el término comercial adecuado. Este cambio tiene mucho sentido y es posible revisarlo.

    
respondido por el Arseni Mourzenko 11.11.2018 - 23:08
2

Calcule lo que está tratando de lograr con revisiones de solicitudes de extracción y vea si hay una alternativa.

Por ejemplo, es posible que desee

  • Asegúrese de que se sigan los estándares
  • Comprobar que la funcionalidad es correcta
  • Asegúrese de que más de una persona entienda el código
  • entrenar juniors

etc. etc.

Algunos de estos pueden ser mejor atendidos por otras cosas, e incluso solo entender las razones le permite limitar el alcance de sus cheques.

Por ejemplo, si estoy marcando todas las líneas para poder sugerir y analizar los cambios para la capacitación, entonces puedo omitir eso en un RP grande realizado por personas mayores

Si necesito entender el código, tal vez haga una programación de pares en funciones grandes y limite la revisión del código a una verificación de estándares.

No es necesario que revise todas las cosas en cada RP, siempre y cuando tenga un enfoque de control de calidad en capas

    
respondido por el Ewan 12.11.2018 - 09:45

Lea otras preguntas en las etiquetas