Debería mejorar la calidad del código mientras trabaja en una rama de características

Realmente me gusta este artículo sobre dejar el código / sitio de campamento en un estado más agradable de lo que lo encontraste ; parece un enfoque práctico en el mundo real mantenerse al tanto de la limpieza del código.

También me gustan las ramas de características como una forma de desarrollar características de forma aislada para que, si no te gusta, no puedas fusionarlas fácilmente, etc.

Sin embargo, si estoy trabajando en una rama de características y veo algún código feo, ¿debería solucionarlo?

Parece que hay una serie de inconvenientes para arreglarlo:

• Cuando vuelva a fusionar la rama, la diferencia será desordenada, abarrotada de renombramientos variables o extracción de funciones
• Si la función se abandona, debe elegir el compromiso de limpieza (que puede o no funcionar dependiendo de cómo ha cambiado el código cercano para hacer una fusión desordenada), volver a hacerlo o simplemente abandonarlo.

Por otro lado, si no lo hago mientras estoy en el archivo, entonces claramente me olvidaré de hacerlo dentro de un par de días cuando fusione la rama.

Me advirtieron que esto estaba basado en la opinión (creo que solo por el hecho que el título incluye should), pero siento que hay una respuesta (ciertamente las personas usan ambos enfoques, por lo que deben tener una respuesta). Además, las preguntas sobre development methodologiesel tema y creo que necesitan un cierto grado de opinión.

Solo debe "arreglar" el código en una rama de la característica si está cambiando ese código de todos modos como parte de la característica.

P.ej. Estoy trabajando en la función 'imprimir conejos' y encuentro el código de la impresora

Public class Printer(string type)
{
    If(type=="bunnies")
    {
        //print a bunny
    }
.....
}

Lo cambio a:

Public class Printer(string type)
{
     PrintFunctionDictionary[type].Print();
}

Por qué:

• Estoy trabajando en el código,
• Necesito cambiarlo para agregar funcionalidad,
• La funcionalidad adicional sugiere una forma refactorizada de abordar el problema.

No golpeo al azar alguna otra parte de la base del código y 'lo hago mejor', ya que esto:

• Choque con personas que trabajan en otras funciones.
• Use el tiempo que debe asignarse para desarrollar la función.
• Agregue código arbitrario a una rama que, si la función no está terminada, no puede fusionarse con el producto principal. Del mismo modo, si revierto la función, perderé mi refactorización.

Si desea que sus refactorizaciones "vivan independientemente" de su rama de características actual, no realice los cambios allí. En cambio, realice la refactorización en la rama de desarrollo principal (o una "rama de refactorización", si es común en su equipo no aplicar cambios directamente a la rama de desarrollo). Por lo tanto, cualquiera de su equipo (incluido usted) puede fusionar los cambios en las ramas de características activas en las que están trabajando. Sin embargo, tenga cuidado de no aplicar ninguna refactorización global en "la mitad de la base del código" sin pedir permiso a sus colegas primero; es posible que no estén tan contentos si sus refactorizaciones interfieren demasiado con su trabajo actual.

La excepción es aquí cuando las mejoras que realiza son locales a las partes de la base de código que toca exactamente en esa rama de características, y no tiene sentido darles un ciclo de vida diferente al de su "nueva característica".

El propósito de los branchtipos es proporcionar la intención de manejarlos. Si usted está siguiendo un estilo GitFlow de ramificación, entonces es probable que tenga tipos como feature, hotfix, release, etc .. En el caso de una rama de la característica, su intención es encapsular fusiones en otra rama (es decir develop) que muestra el desarrollador responsable de fusionando, cuál es esta característica. Si el código que está limpiando no forma parte de esa función, no lo cambie.

En su lugar, encuentre la rama más baja posible en la que se encuentra el código feo (probable develop) y bifurque desde allí. Cambie el código y proponga fusionarlo como una característica. Si necesita ese código en lo que está trabajando y especialmente desea evitar conflictos de fusión, combine esa rama en SU ​​rama.

Aquí hay una muy buena explicación de diferentes estrategias: https://www.atlassian.com/git/tutorials/comparing-workflows/

si estoy trabajando en una rama de características y veo un código feo, ¿debería solucionarlo?

Probablemente esté bien arreglar el 'código feo' a la vista, dependiendo del tempo del proyecto, la 'fealdad' del código, etc., pero trate de no hacerlo en la rama de la característica.

• Si su rama de características es completamente local, solo guarde o confirme los cambios no guardados, revise la rama de desarrollo, realice el cambio, luego regrese a su rama de características y desactive el desarrollo.
• Si no puede reducir el desarrollo (p. Ej., Su rama de características está en un servidor público), aún puede seleccionar el desarrollo de confirmación si lo necesita o desea evitar conflictos más adelante.
• Si está editando un archivo y realmente tiene que confirmar el arreglo en el código feo en este momento y realmente no puede cambiar para desarrollar, puede hacer el arreglo, usar git add -ppara hacer el arreglo, confirmar ese cambio solamente , y antes de fusionar / push (de hecho, preferiblemente después de su próximo commit), use rebase interactivo para mover ese commit al punto más temprano posible en su rama, o posiblemente incluso elegir el desarrollo, dependiendo de su historial.

También haría esto con cualquier otra cosa que esté 'arreglando' la rama de desarrollo (donde 'arreglos' son cambios que usted o cualquier otro desarrollador podrían hacer a la vista para asegurarse de que el código se adhiera a los estándares). Esto ayuda...

• para mantener sus correcciones y sus confirmaciones de características en diferentes grupos para que el registro sea más legible,
• para mantener el desarrollo lo más cerca posible de ser liberable en cualquier momento, y
• para evitar la duplicación de trabajo (varias personas arreglan el mismo problema de manera sutilmente diferente en diferentes ramas).