¿Cómo deben comprometerse los cambios no funcionales?

8

Estoy trabajando en una base de código heredada de pequeña a mediana y cuando trabajo en un ticket, encontraré un código que debería limpiarse o que necesito limpiar solo para poder entender el seguimiento de la aplicación.

Un ejemplo real es:

if( !a && b ){
     doSomething1();
     doSomething2();
     doSomething3();
     doSomething4();
     doSomething5();
}else if( a ){
     doSomething1();
     doSomething2();
     doSomething3();
     doSomething4();
     doSomething5();
}else if( !b && ( a || c )  ){
     doSomething1();
     doSomething2();
     doSomething3();
     doSomething4();
     doSomething5();
}

Otro es corregir errores tipográficos y Engrish en comentarios y documentación en una docena de archivos fuente.

Sin embargo, a menudo esta limpieza no está relacionada con el problema principal y me pregunto cómo es mejor realizar la limpieza. A mi modo de ver, hay tres opciones:

Antes de la solución: esto funciona cronológicamente ya que este es el orden en que ocurren, pero si rompen algo complican la solución y hace que sea más difícil diferenciar la solución con lo que estaba en producción. También introduce un commit adicional que es ruido.
Con la solución: pero eso oculta el reemplazo real del código defectuoso con archivos donde findGeoragphyfue correcto findGeography.
Después de la corrección: esto requiere eliminar y limpiar lo que hizo que lo ayudó a comprender el código y luego volver a probar la corrección, confirmarla y luego volver y rehacer la limpieza. Esto permite la diferencia más clara del código defectuoso, pero duplica el esfuerzo y puede conducir a confirmaciones espurias también.

tl; dr: Entonces, ¿cuál es el mejor método para confirmar el código de limpieza?

Contexto: no tenemos pruebas unitarias y el desarrollo se lleva a cabo ejecutando cambios y ocultándolos y arrojándolos por encima del muro al control de calidad para validarlos mediante correcciones de regresión manual. Además, si no hacemos algunas limpiezas de formularios, el código se vuelve ininteligible. Sé que esto está lejos de ser ideal, pero este es un verdadero desarrollo empresarial que pone comida en mi mesa y no es mi elección.

version-control

— Trineo
fuente

¿Sin pruebas unitarias? ¿Por qué no escribirlo antes de la solución? (si corresponde)

— Wolf

El código no era comprobable por unidad porque dependía en gran medida de la base de datos y no había una especificación de lo que debía hacer, por lo que las pruebas unitarias habrían sido "testStillDoesWhatItDoes ()" en lugar de algo de comportamiento o semántico y con violaciones de capas habría sido muy difícil de burlarse también. Además, muchos de los cambios tuvieron oportunidad, como corregir los nombres de los métodos de Engrish tal como los conocí, pero no tuve tiempo para escribir pruebas y, de lo contrario, permanecerían en Engrish.

— Trineo

ver también: ¿Vale la pena comprometerse únicamente para resolver errores tipográficos no críticos?

— mosquito

11

Sigo un proceso similar a la respuesta de Karl. Prefiero una confirmación por separado de la limpieza / refactorización antes de los cambios de características por algunas razones:

Separar los dos commits explicará su proceso y pensará mejor a los demás que miran los registros.
Proporciona un conjunto específico de cambios útiles durante una revisión de código.
Significa que si desea revertir los cambios de sus características, aún conserva la limpieza / refactorización.
Los cambios de limpieza se pueden probar por separado y antes de las actualizaciones de funciones.

— Matt S
fuente

6

Prefiero el commit adicional antes de la solución. Esto separa claramente las dos tareas que está haciendo y permite que otras personas vean qué fue la limpieza versus qué fue una corrección de errores. Además, la limpieza (al menos para mí) suele ser mucho más rápida, por lo que si cometo una solución de limpieza, no tengo que preocuparme tanto por que alguien haga un cambio difícil de fusionar mientras trabajo por más tiempo tarea.

Yo he utilizado el "comprometerse con la solución" enfoque en los lugares con las políticas que requieren una identificación de solicitud de cambio con cada cometen, y que no permiten a los desarrolladores crear nuevas solicitudes de cambio sólo para el código de limpieza. Sí, tales políticas son improductivas, pero existen lugares de trabajo como ese.

— Karl Bielefeldt
fuente

55

Con respecto al segundo párrafo: en tales situaciones, a veces reutilizo el ID del ticket de la solución que estoy haciendo, pero aún pongo la limpieza en una confirmación por separado.

— Bart van Ingen Schenau

0

Si es posible que el parche tenga que ser parcheado en una versión existente, primero debe revisar el parche y luego la limpieza, o bien (al menos parte del tiempo) está haciendo la persona que necesita aplicar el parche. trabajar más duro de lo necesario (ya sea para comprender qué cambió o para parchear los cambios cosméticos antes de reparar la solución real (notaré que he realizado más de unos pocos cambios cosméticos que terminaron rompiendo algo, por lo que parchear más de El cambio mínimo para corregir un defecto puede aumentar el riesgo de liberar algo malo).

Sí, esto es trabajo extra. Si, es un dolor. Pero sí, es la forma correcta de hacer las cosas. Mi flujo de trabajo normal es hacer todo en una caja de arena (limpieza y corrección de defectos), luego crear una nueva caja de arena, aplicar solo el cambio mínimo de reparación de defectos, verificar este cambio en la caja de arena original y verificar la limpieza. código arriba No es mucho trabajo extra, en mi experiencia.

— James McLeod
fuente