¡Continúe creando, acelere el crecimiento! Este es el octavo día de mi participación en el "Nuevo plan diario de Nuggets · Desafío de actualización de junio", haga clic para ver los detalles del evento
CONSEJOS: El siguiente lenguaje de ejemplo de código es Go
Descripción del problema
Xiao A y yo estamos desarrollando en paralelo, él está optimizando la lógica del código antes y estoy desarrollando nuevas funciones.
Xiao A envió el código a la rama de prueba antes que yo, y encontré muchos conflictos cuando quería enviar mi nuevo código de función a la rama de prueba.
Resolver conflictos primero es una pérdida de tiempo, y necesito resolver conflictos cada vez que se prueba mi nuevo código de función.
Además, cuando pruebo la rama para resolver el conflicto, solo puedo resolverlo de acuerdo con la lógica de código optimizada por Xiao A, que no es consistente con mi propia lógica de rama.
El código entregado a los compañeros de prueba es inconsistente con el código de mi propia rama, este tipo de prueba no tiene sentido.
Reflexionar sobre lo que salió mal
-
Uso irrazonable del modo de fábrica
-
Asignación irrazonable de tareas.
nivel de código
Debido a que es el patrón de diseño de fábrica, la clase de implementación A de la que soy responsable no está directamente relacionada con su clase de implementación B. Pero porque modificó la definición del método en la clase de fábrica.
Por ejemplo, la interfaz en la clase de fábrica anterior se define así
package factory
type xxx interface {
GetXxxx(ctx context.Context, req aaa.aa) (res bbb.bb, err error)
}
复制代码
Pero Xiao A modificó la definición de interfaz en la clase de fábrica:
package factory
type xxx interface {
GetXxxx(ctx context.Context, req ccc.cc) (res ddd.dd, err error)
}
复制代码
Esto lleva a un problema:
Si quiero fusionar mi código en la rama de prueba, también tengo que modificar el tipo de parámetro y el tipo de retorno de mi clase de implementación A.
Pero todos nos estamos desarrollando en diferentes ramas, y no tengo el tipo definido por ccc.cc
él ddd.dd
.
No puedo definirlo directamente ccc.cc
. ddd.dd
Quiero venir y desarrollar mi propia sucursal. Primero, debido a los requisitos inconsistentes, el ciclo en línea de Xiao A será más largo que el mío. Segundo, esta operación en sí no está estandarizada.
Resolver el problema
Optimizar desde el diseño del código:
La solución que pensamos es usar la interfaz razonablemente
Establezca los parámetros de entrada y salida del método de interfaz que se implementará en la clase de fábrica al interface{}
tipo
package factory
type xxx interface {
GetXxxx(ctx context.Context, req interface{}) (res interface{}, err error)
}
复制代码
Esto facilita la expansión.
Optimizar desde operaciones de git:
Pero el método de establecer los parámetros de entrada y salida como interface{}
tipos no resolvió fundamentalmente nuestro problema.
La razón es esta:
El requisito de la pequeña A es optimizar los parámetros de entrada y salida de la clase de fábrica y cada clase de implementación en su conjunto, optimizar la lógica interna y extraer métodos.
La modificación de la pequeña A genera un gran conflicto con mi lógica de implementación.
Pero su envío de git se envió al entorno de prueba antes que yo, por lo que no pude enviar mi código. Si quería enviarlo, tenía que resolver varios conflictos. Para resolver el conflicto, debemos cambiarlo de acuerdo con la lógica de optimización de Xiao A, y las pruebas dadas a los estudiantes de prueba son inconsistentes con mi propia rama.
Difícil de superar.
Teniendo en cuenta que la modificación de la pequeña A no necesita ser probada por el momento, el ciclo en línea también es relativamente largo.
La solución final es esta:
Sacó una rama de respaldo de la rama de prueba remota
eliminar la rama de prueba remota
Envíe la sucursal que necesito probar localmente a la sucursal de prueba y entregue la prueba.
git cambiar el nombre de la rama remota
1. Cambiar el nombre de la sucursal local primero
git branch -m 旧分支名称 新分支名称
复制代码
2. Eliminar la sucursal remota
git push --delete origin 旧分支名称
复制代码
3. Sube la sucursal local con el nuevo nombre modificado
git push origin 新分支名称
复制代码
4. La sucursal local modificada se asocia con la sucursal remota
git branch --set-upstream-to origin/新分支名称
复制代码
Resumir
Es genial desarrollar y mantener un crematorio.
La operación no está estandarizada y los familiares lloran.
Al final
Gracias por leer y bienvenidos a todos: me gusta, favorito,moneda(concentrarse en)! ! !