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 correctofindGeography. - 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.
fuente
Respuestas:
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:
fuente
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.
fuente
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.
fuente