Resolver conflictos de combinación debido a la refactorización

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

Prevención

Una combinación de integración continua y hacer refactorizaciones pequeñas con frecuencia (en lugar de refactorizaciones grandes 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 proceso de fusión.

Los conflictos se producen solo cuando dos o más desarrolladores están trabajando en el mismo archivo al mismo tiempo y ambos intentan registrarse. El primer desarrollador no lo hará. obtener cualquier conflicto, por supuesto. Pero el segundo (tercero, cuarto, y así sucesivamente) 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 desde el estilo, como usar new UserManager().GetUserName() en lugar de UserManager userManager = new UserManager(); userManager.GetUserName(); hasta el nivel que mencionó, lo que significa que ambos desarrolladores tenían ideas diferentes de 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 tener en cuenta los conflictos. Ellos deben y deben abordar esos conflictos. Si los conflictos no son importantes, entonces pueden registrar 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 obtener 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 superponga, esto significa que al menos en algunos lugares, hay 2 soluciones diferentes. Por lo tanto, una de esas soluciones debe ser discutida y aceptada, por lo tanto registrada, como la mejor solución.

No estoy de acuerdo en prevenir estas circunstancias, ya que deberíamos ser más reales que teóricos. A veces, un tipo es realmente 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 en lo real (no en lo ideal), podemos ver que muchas veces ocurre este fenómeno (conflicto).

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

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

Sin embargo, si tienes una reunión diaria de pie o un administrador , no puedes tener este problema.

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

Esto se evita trivialmente hablando.

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

Y se comunican . Hable con otros desarrolladores sobre el código, incluso al iniciar. Incluso cuando se codifica))

Asegúrese de que la combinación sea lo más sencilla posible. Refactorización es generalmente un proceso bastante mecánico que cambia muchas líneas existentes : Mueve 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 da como resultado nuevo código más algunos pequeños ajustes en el 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 hacerlo al revés. En base a esto, diría que, como regla general, debe aplicar el cambio más complejo primero, seguido de cambios cada vez más simples.