it-swarm-es.com

Corregir un error mientras trabajaba en una parte diferente del código base

Esto me pasó al menos una vez. Estoy trabajando en una parte del código base y encuentro un pequeño error en una parte diferente, y el error me impide completar lo que estoy intentando hacer actualmente. Arreglar el error podría ser tan simple como cambiar una sola declaración.

¿Qué haces en esa situación?

  1. Corrija el error y envíelo junto con su trabajo actual
  2. Guarde su trabajo actual en otro lugar, corrija el error en una confirmación separada y luego continúe con su trabajo [1]
  3. Continúe con lo que se supone que debe hacer, confirme el código (incluso si rompe la construcción falla algunas pruebas), luego corrige el error (y la construcción hacer que las pruebas pasen) en una confirmación separada

[1] En la práctica, esto significaría: clonar el repositorio original en otro lugar, corregir el error, confirmar/enviar los cambios, extraer la confirmación del repositorio en el que está trabajando, fusionar los cambios y continuar con su trabajo.

Editar : Cambié el número tres para reflejar lo que realmente quise decir.

22
imgx64

He hecho 1 y 2 y al final, creo que prefiero el # 2. Permite una mayor visibilidad de la corrección de errores, que puede ser importante para QA/notas de lanzamiento/otros desarrolladores.

También me encontré con una situación en la que lo que pensé que era un error en realidad no lo era (sin decir que este sea el caso aquí), y "arreglarlo" en una confirmación separada permitió que otro desarrollador se pusiera en contacto conmigo y explicara qué era qué en lugar de que la "solución" se pierda en mi registro normal.

16
Adam Lear

Por lo general, elijo el número 2. Hace que el repositorio esté más limpio y hace que los registros sean más comprensibles. Odio cuando otros desarrolladores con los que trabajo cometen 15 correcciones de errores, funciones y refactorizaciones diferentes, todas en la misma confirmación.

Además, dependiendo de cómo su equipo realice el seguimiento de defectos, es posible que deba buscar el repositorio de defectos para asegurarse de que si el defecto que está reparando está allí, marque el artículo como completo. O puede que necesite crear un nuevo artículo y marcarlo como completo para que el sistema de defectos y el repositorio de códigos coincidan.

12
RationalGeek

Yo hago # 2. El uso de herramientas como git hace que sea trivial dividirlo en múltiples confirmaciones. Si no puede convencer a su equipo de que cambie a herramientas más modernas, git-svn le dará una porción decente de lo que usaría para resolver este problema. Esta publicación de blog ofrece una buena descripción general del flujo de trabajo que está tratando de resolver: Lo que pasa con Git

7
Daenyth

Elijo la opción no escrita (4): Divida su proyecto en ensamblajes/bibliotecas altamente especializados, de modo que los errores no relacionados siempre estarán en una ubicación diferente en el árbol de control de versiones.

Me disculpo si lo anterior suena sarcástico, pero lo digo sinceramente. Me estremezco cada vez que veo un proyecto monolítico con cientos de formas y espacios de nombres que no tienen nada que ver entre sí. Solía ​​enfrentar este mismo dilema a menudo, preguntándome si y cómo debería romper los compromisos que trataban con diferentes áreas funcionales; No fue hasta mucho después que me di cuenta de que tener todas estas áreas funcionales diferentes en un solo proyecto comprometible era, en sí mismo, un defecto de diseño importante.

Todavía encuentro con frecuencia errores totalmente ajenos mientras trabajo en una función específica. Es posible que esté trabajando en la interfaz de usuario y encuentre un error en alguna lógica empresarial, y tenga que solucionarlo antes de poder seguir adelante. La diferencia es que la lógica empresarial es siempre en un ensamblaje/proyecto diferente de la interfaz de usuario, por lo que todo lo que tengo que hacer es hacer un cambio muy pequeño en el BL y continuar con uno compromiso muy pequeño, luego sigue trabajando.

Tener una organización de proyecto realmente buena hace que no solo sea posible, sino también bastante fácil manejar estos problemas sin enterrar un cambio, romper la compilación o quedar atrapado en una rama/fusión irritante (incluso si está utilizando un DVCS no lo es totalmente indoloro).

Si no tiene esta opción, es decir, es un desarrollador junior sin voz en la organización del proyecto, entonces simplemente iría con el n. ° 1 y tomaría las notas apropiadas en el registro para que otras personas sepan por qué hizo lo que hizo. Si ha realizado un cambio importante , presente también un informe de error en su sistema de seguimiento de problemas para dar visibilidad a lo que ha solucionado y por qué.

4
Aaronaught

Por lo general, solo soluciono el error y luego continúo con lo que estaba trabajando. Cuando llega el momento de comprometerse, asumiendo que la corrección de errores está en un archivo separado, hago dos confirmaciones simultáneas - la primera es una confirmación parcial que contiene solo la corrección de errores, y el segundo es todo lo demás.

Arreglo el error y lo hago confirmaciones separadas, una para cada corrección/característica.

La mayoría de las veces, los cambios no están en el mismo archivo, por lo que es fácil separar las confirmaciones. Si los cambios están en el mismo archivo, utilizo TortoiseHg (una interfaz gráfica de usuario mecurial) para seleccionar precisamente las diferencias que quiero confirmar (creo que es posible hacer esto en la línea de comando con la extensión de registro, pero es menos conveniente).

Algunas personas usan Colas Mercurial para aislar las correcciones menores mientras trabajan en una función. Las correcciones menores se apilan en el MQ, y cuando la característica se termina y se confirma, el contenido de la cola también se confirma (un conjunto de cambios para cada entrada en la cola).

1
barjak

Intento hacer el # 2. Si realmente se trata de un problema independiente, es muy probable que esté en un archivo diferente al que está trabajando. Debería poder registrar el archivo como una confirmación separada, incluso si está hecho en el mismo repositorio en el que está trabajando. Por todas las razones mencionadas anteriormente, tiene sentido tener confirmaciones lo más independientes posible, para rastrear y revertir el cambio si es incorrecto.

1
KeithB

Respuesta corta: # 2. Realmente desea que esa corrección de errores (¡con su nota en su rastreador!) Esté etiquetada en su historial de versiones como una entidad separada.

Respuesta más larga:

  • Tropezar con el error
  • Escribe una prueba o más demostrando el error.
  • Haz que la prueba pase
  • Confirme solo ese cambio y sus pruebas (git add --interactive o darcs record -i o como lo haga su VCS) (*)
  • Vuelve a lo que estaba haciendo.

(*) En CVS (no, de verdad) a veces tengo un árbol limpio y una copia en la que trabajo. Luego utilizo una combinación, winmerge, en mi caso, para colocar solo la corrección de errores en el árbol limpio para poder cometerlo por separado. (La otra opción es cambiar el nombre de los archivos modificados, cvs update y fusionar. Cuando haya realizado el cambio, elimine el archivo y cambie el nombre de los archivos movidos a sus nombres originales).

Sin embargo, algo a tener en cuenta es que generalmente solo encuentro errores que están relacionados con lo que estoy trabajando o que están muy cerca léxica. Me sorprendería que fuera normal que las personas encontraran errores en partes no relacionadas del código base. ¿Por qué estás leyendo código no relacionado al corregir el error? (Sí, ¡esto es exactamente lo contrario de lo que dice Aaronnaught!)

1
Frank Shearar

Hacemos el # 1. El # 2 suena bien, pero no puedo decir que hayamos tenido problemas con el # 1 que el # 2 solucionaría.

Un factor adicional en mi empresa es que creamos aplicaciones web, y nuestras pruebas se realizan casi en su totalidad a través de la interfaz web, más o menos, lo que la gente llama pruebas funcionales en lugar de pruebas unitarias. Hacemos que todas las pruebas pasen antes de registrarnos. Dividir las confirmaciones en bits más pequeños significaría ejecutar las pruebas una vez para cada bit, y eso llevaría más tiempo. Me encantaría tener un conjunto de pruebas mucho más rápido, que nos permitiría hacer confirmaciones más pequeñas, pero simplemente no lo tenemos.

0
Tom Anderson

Yo suelo hacer el # 2. Guardar mi trabajo actual en otro lugar: esto suele funcionar bien creando un parche. Además, algunos IDE (IntelliJ) permiten archivar los cambios, que es exactamente eso: guarde el trabajo actual en otro lugar.

0
michid

Lo que hago depende de si el error realmente está en una parte diferente. Si es así, registrarlo es independiente de mis cambios a medio hacer. Hago el cambio, construyo esa parte diferente para asegurarme de que no he cometido un error trivial, la pruebo (tal vez haciendo lo que sea que me impidiera hacer) y la reviso para explicar lo que estaba sucediendo. A menudo, haré un elemento de trabajo para él y, después de registrar/resolver, asignaré el WI a un probador. Luego vuelvo a lo que estaba haciendo.

Si todo está mezclado con los archivos que he cambiado a medias, no puedo construir y probar esa parte de forma independiente. En ese caso, hago otro WI para ello y cuando reviso mis cambios resuelvo ambos WI con el mismo checkin, lo que generalmente va en contra de mis principios, pero se aplica bien en este caso.

En ambas circunstancias, la corrección de errores termina probada por mí, verificada con algún tipo de rastro para que la gente entienda por qué cambié ese código al azar ese día, y se asigna un WI a otra persona para confirmar que es correcto ahora.

0
Kate Gregory