Resolver conflictos de fusión debido a refactorización

Recientemente me involucré en una discusión sobre cómo manejar la refactorización en general (que es un tema interesante en sí mismo). Finalmente, se planteó la siguiente pregunta:

¿Cómo se manejan los conflictos de fusión que ocurrieron debido a que alguien realizó una refactorización de una parte del código, mientras que alguien más estaba trabajando en una función para el mismo fragmento de código?

Básicamente, no tengo idea de cómo lidiar con esto de manera eficiente. ¿Hay alguna mejor práctica que uno deba seguir con respecto a esto? ¿Hay alguna diferencia en cómo se debe manejar esto para un sistema con toneladas de código heredado?

Buena pregunta. La mejor estrategia que se me ocurre es:

Prevención

Una combinación de integración continua y la realización de pequeñas refactorizaciones a menudo (en lugar de grandes refactorizaciones ocasionales) contribuirá en gran medida a minimizar el costo y la frecuencia de tales conflictos.

Creo que para responder a su pregunta, primero tenemos que ver por qué ocurren los conflictos y cuál es el verdadero significado y el proceso de fusión.

Los conflictos ocurren solo cuando dos o más desarrolladores están trabajando en el mismo archivo al mismo tiempo y luego ambos intentan registrarse. El primer desarrollador no tendrá ningún conflicto, por supuesto. Pero el segundo (tercero, cuarto, etc.) tendría conflictos. Por qué, porque tiene un código que es parcial o totalmente diferente del código existente en el servidor.

Esto en la naturaleza significa que el segundo desarrollador tiene algo en mente diferente al primer desarrollador. Esta diferencia puede variar del estilo, como usar en new UserManager().GetUserName()lugar del UserManager userManager = new UserManager(); userManager.GetUserName();nivel que mencionó, lo que significa que ambos desarrolladores tenían ideas diferentes sobre cómo refactorizar el código para mejorarlo.

La fusión, por otro lado, no significa que los desarrolladores puedan registrar su código sin considerar conflictos. Ellos deben y tienen que hacer frente a esos conflictos. Si los conflictos no son importantes, pueden registrarse y anular el código anterior. Pero cuando ven algo completamente diferente, deben llamar al desarrollador anterior y hablar con él, para que ambos puedan coordinarse juntos para registrar la mejor solución.

Por ejemplo, si le pide a dos desarrolladores que mejoren la biblioteca de pagos en línea, y su trabajo se superpone, esto significa que al menos en algunos lugares, hay 2 soluciones diferentes. Por lo tanto, una de esas soluciones debe ser comentada y aceptada, por lo tanto, registrada como la mejor solución.

No estoy de acuerdo en prevenir estas circunstancias, ya que deberíamos tender a ser más reales que teóricos. A veces, un chico es muy bueno en CSS, mientras que otro es realmente bueno en ASP.NET Markup. Pero su trabajo puede entrar en conflicto cuando ambos deberían trabajar en la página de inicio de sesión para que funcione. Quiero decir, si pensamos real (no ideal), podemos ver que muchas veces este fenómeno (conflicto) ocurre.

Otro punto que solo quería mencionar es utilizar herramientas para ayudarlo en su proceso de registro. Estas herramientas generalmente visualizan la diferencia del código del servidor y el código del desarrollador, y ayudan mucho a determinar qué parte debe registrarse.

Si no hay una gestión activa de las tareas, tiene conflictos.

Sin embargo, si tiene una reunión diaria o un gerente , no puede tener este problema.

Habla (a través de un stand up diario) o habla con un gerente.

Esto se evita trivialmente hablando.

Tenga una rama común separada para desarrollar una determinada característica, fusionar / extraer / empujar a menudo, eso es todo.

Y comunicarse . Hable con otros desarrolladores sobre el código incluso cuando se inicie. Incluso cuando se codifica)))

Asegúrese de que la fusión sea lo más simple posible. La refactorización suele ser un proceso bastante mecánico que cambia muchas líneas existentes : mover declaraciones de variables, cambios de espacios en blanco, formateo, secuencia de operaciones. La creación de características suele ser una empresa mucho más creativa, que a menudo resulta en un nuevo código más algunos pequeños ajustes al código existente. Ahora, si el desarrollador que realiza la refactorización registra los pasos (por ejemplo, como expresiones regulares), puede ser mucho más fácil aplicarlos al código con la funcionalidad adicional en lugar de al revés. En base a esto, diría que, como regla general , primero debe aplicar el cambio más complejo, seguido de cambios progresivamente más simples.