Experiencia en la reconstrucción del negocio de reembolsos del sistema posventa de la ciudad | Equipo técnico de JD Cloud

Desde datos hasta aplicaciones de modelos grandes, el 25 de noviembre se celebró la Conferencia Hangzhou Yuanchuang para compartir consejos de desarrollo.

1. Reconstruyendo el fondo

1.1 Reembolso

Hay dos estructuras para Entrega a domicilio, Compra por hora y Reembolso de Tianxuan , y la lógica del código es confusa;

Entre ellos, algunos pedidos de posventa para compras por horas y Tianxuan se reembolsan de forma interactiva con Hepingsheng pop, y algunos se reembolsan de forma interactiva con el centro de posventa, y son compatibles con 3 conjuntos de lógica;

Puntos débiles : código pesado, falta de diseño racional, altos costos de mantenimiento y desarrollo iterativo posterior y mayores riesgos e inestabilidad del sistema.

1.2 Cálculo del importe

Hay dos conjuntos independientes de cálculo de estructura lógica para entrega a domicilio y compras por horas. Sobre esta base, se implementan dos conjuntos de lógica para reembolso y no reembolso ;

El cálculo de la cantidad para la dimensión de la pieza del producto, la dimensión de la línea de producto y la dimensión única de posventa es confuso y faltan límites de dominio y diseño jerárquico ;

Puntos débiles : el cálculo de las cantidades en la dimensión única de posventa, la dimensión de la línea de productos y la dimensión de la pieza dividida es confuso y el código carece de una estructura jerárquica ; hay problemas con la legibilidad del código , los costos de mantenimiento y la escalabilidad posterior.

1.3 Cuenta inversa posventa

La interfaz de detalles del pedido posventa y la interfaz de detalles del pedido de queja tienen dos conjuntos de lógica para la entrega a domicilio y la compra por horas;

Entre ellos, la interfaz de detalles del pedido posventa tiene 5 conjuntos de procesamiento lógico para la lista negra de compras por horas, la lista blanca de compras por horas, Tianxuan, reembolso a domicilio y no reembolso a domicilio ;

Además, estas dos interfaces obtienen el monto de la división en tiempo real para el cálculo de la división inversa posventa, y pueden obtener y asignar valores directamente de la base de datos, sin la necesidad de realizar un cálculo de división posventa unidimensional;

Puntos débiles : una gran cantidad de código redundante , altos costos de cambio , mayores riesgos e inestabilidad del sistema

2. Ideas y planes de reconstrucción.

2.1 Ideas de reconstrucción

¿Qué es la refactorización?

Sustantivo : Un ajuste a la estructura interna del software con el propósito de mejorar su comprensibilidad y reducir sus costos de modificación sin cambiar el comportamiento observado del software;

Verbo : Utiliza una serie de técnicas para ajustar la estructura del software sin cambiar su comportamiento observable.

El propósito de la refactorización es hacer que el sistema o código sea más fácil de entender, modificar e iterar.

El secreto de la refactorización: sea audaz y cuidadoso

Negrita (significa tener el coraje y la determinación de cambiar y mejorar el código existente. La refactorización puede implicar modificaciones en estructuras de código complejas e incluso puede requerir reescribir partes del código. Los desarrolladores audaces están dispuestos a enfrentar estos desafíos y creen que los cambios pueden conducir a mejores resultados). )

Cuidadoso (se refiere a mantener un pensamiento y una acción meticulosos al refactorizar. Esto incluye analizar cuidadosamente la estructura y la lógica del código, comprender la función y las dependencias del código y considerar el impacto potencial que cada paso de refactorización puede traer. Los desarrolladores cuidadosos manejarán con cuidado cada detalle durante el proceso de refactorización para garantizar la corrección y mantenibilidad del código)

1. Aproveche la oportunidad para refactorizar: cuando encuentro que el código de los módulos comerciales, como los reembolsos posventa y los cálculos de montos, tiene problemas de calidad, mala legibilidad, mala mantenibilidad o mal gusto, y cuando el cronograma de demanda del proyecto no es ajustado, es un buen momento para refactorizar;

2. La clasificación preliminar es muy importante, encontrar primero los puntos débiles, no conviene luchar a largo plazo o en paralelo con el negocio.

3. Aclarar objetivos y valores: los reembolsos posventa y los cálculos de montos se pueden reconstruir para mejorar la eficiencia del desarrollo, reducir los costos de mantenimiento y desarrollo, etc.

4. Determine el objetivo de la refactorización: en primer lugar, debe aclarar los bloques de código o funciones que deben refactorizarse y aclarar cuál es el objetivo de la refactorización. Por ejemplo, puede ser necesario mejorar la legibilidad, el mantenimiento o el rendimiento del código.

5. Analice los olores del código: utilice herramientas de análisis estático de código o verifique manualmente el código para identificar posibles olores del código , por ejemplo, hay más de 1000 líneas de clases, más de 600 líneas de métodos, demasiados parámetros variables y muchos Código duplicado y otros malos olores a código .

6. Elija la tecnología de refactorización adecuada: elija la tecnología de refactorización adecuada según el tipo de mal olor en el código posventa y el objetivo de la refactorización. Las técnicas de refactorización que uso son: refactorización a pequeña escala-->refactorización a gran escala-->patrón de diseño de nivel superior; uso la idea de primero lo pequeño, luego lo grande, y de grande a completo para refactorizar el diseño. . Refactorización a pequeña escala : extraer métodos, eliminar clases o métodos de funciones muy grandes, extraer clases, renombrar, fusionar código duplicado, etc.; refactorización a gran escala: adoptar capas, modularización, desacoplamiento, reutilización abstracta, etc. Técnica; Patrón de diseño : El negocio de reembolso adopta el patrón estratégico + fábrica abstracta; el negocio de cálculo de montos adopta el patrón estratégico + fábrica abstracta + patrón de cadena de responsabilidad

7. Escriba casos de prueba: antes de refactorizar, escriba casos de prueba apropiados para verificar la exactitud del código refactorizado. Los casos de prueba deben cubrir varios escenarios de la funcionalidad o el bloque de código refactorizado.

8. Realizar refactorización: Modifique el código paso a paso según la técnica de refactorización seleccionada. Asegúrese de que cada código modificado aún pase los casos de prueba escritos previamente.

9. Ejecute casos de prueba: después de cada refactorización, ejecute los casos de prueba escritos previamente para asegurarse de que el código refactorizado siga siendo correcto.

10. Evaluación del código después de la refactorización: evalúe si el código refactorizado ha logrado los objetivos esperados, como si ha mejorado la legibilidad, la mantenibilidad o el rendimiento del código.

2.2 Plan de reconstrucción

2.2.1 Diagrama de interacción del sistema antes de la reconstrucción.

2.2.2 Diagrama de interacción del sistema después de la reconstrucción.

 El negocio de reembolso está fuertemente acoplado al sistema de posventa y el código comercial está disperso en varias capas comerciales. Existe una grave falta de límites de dominio y diseño jerárquico del sistema. Después de la reconstrucción, la lógica comercial de reembolso no depende en gran medida. basado en la lógica empresarial central de posventa y se puede implementar de forma independiente.

2.2.3 Diagrama de flujo de cálculo de montos antes de la reconstrucción

 2.2.4 Diagrama de flujo de cálculo de importes después de la reconstrucción



 Utilice patrones de diseño para fusionar dos conjuntos de lógica empresarial de cálculo de cantidades en un conjunto de lógica empresarial de cálculo de cantidades para crear una capa anticorrosión.

2.3 Reconstruir el diagrama de clases de diseño.

Basado en el diagrama de flujo de diseño formulado anteriormente, dibujé un diagrama de clases UML. El siguiente es un diagrama de clases para el módulo comercial de cálculo de cantidades.

2.3.1 Diagrama de clases de patrón de estrategia y fábrica abstracta



2.3.2 Diagrama de clases del modelo de cadena de responsabilidad



3. Garantía de estabilidad del sistema

3.1. Reconstrucción en pequeños pasos

Divida la reconstrucción posventa en tres pasos: reembolso, cálculo de importes y contabilidad inversa, y ejecute casos de prueba después de cada paso. Esto permite descubrir y corregir errores introducidos de manera oportuna, evitando que se propaguen por todo el sistema.

3.2 Verificación paso a paso

Después de cada paso de refactorización, realice una verificación paso a paso del sistema. La escala de grises se lanza en lotes y las configuraciones de escala de grises están absolutamente aisladas y no se pueden reutilizar. Asegúrese de que varias partes del sistema funcionen correctamente y se coordinen bien con otras partes durante el proceso de refactorización.

3.3 Monitoreo y pruebas de desempeño

Una vez completada la refactorización, realice la supervisión del sistema y las pruebas de rendimiento para garantizar que la refactorización no introduzca problemas de rendimiento ni afecte la estabilidad del sistema. Si se encuentran problemas, repárelos y optimícelos a tiempo.

3.4 Revisión y prueba del código del equipo

Colabore con los miembros del equipo y realice revisiones de código al refactorizar. Las perspectivas y experiencias de varias personas pueden ayudar a descubrir problemas potenciales y proporcionar sugerencias de mejora; el análisis en profundidad del código refactorizado puede garantizar de manera más efectiva la seguridad de la refactorización.

El negocio de refactorización notifica a los evaluadores de manera oportuna, para que puedan evaluar los puntos de prueba y mejorar los casos de prueba.

3.5 Pasos en escala de grises

3.5.1, comparación y verificación continua de bcp

3.5.2 Según la escala de grises del comerciante

Realice gradualmente el corte en escala de grises de acuerdo con el orden de pedidos posventa pequeños -> medianos -> grandes y observe si los datos del pedido posventa, como el reembolso y el cálculo del monto, son anormales.

4. Resultados de la reconstrucción

1. Reducir los costos de desarrollo y mantenimiento.

2. Mejorar la calidad del código y la estabilidad del sistema.

3. Mejora de la escalabilidad y flexibilidad del sistema;

4. La aplicación del sistema y el posicionamiento de los límites comerciales son más claros.

5. Unificar y estandarizar el contexto empresarial central de posventa, reducir los costos de aprendizaje empresarial y mejorar la eficiencia del desarrollo.

6. Mejore sus habilidades técnicas, conciencia de la calidad del código, habilidades de resolución de problemas, trabajo en equipo y habilidades de comunicación, hay un pasaje en el libro clásico "Refactoring":

Al principio, la refactorización que hice se basó en minucias. A medida que el código se vuelve más conciso, descubro que puedo ver algunas cosas a nivel de diseño que antes no podía entender. Sin refactorizar, no podría alcanzar este nivel.

5. mostrar código

5.1 Cálculo del importe antes de la reconstrucción

Método de servicio para calcular el importe de los pedidos de posventa a domicilio.

Método del servicio de cálculo del monto del pedido posventa de Jingdong

Una clase de cálculo de grandes cantidades tiene más de 1000 líneas de código y cada método tiene cientos de líneas de código. A continuación se muestra parte del código para calcular el monto de un pedido posventa.

 5.2 Cálculo del importe después de la reconstrucción

Se utiliza la misma interfaz para calcular el monto del pedido posventa de Daojia y JD.com, y el modelo de fábrica abstracto de política + se usa para realizar el cálculo del monto de Daojia, la compra por hora y el negocio de Tianxuan.



Modo de estrategia para obtener el conjunto de resultados de división de cantidad



El método principal de cálculo de montos solo tiene 4 pasos



El núcleo del cálculo del importe se calcula utilizando la cadena de responsabilidad empresarial.



La dimensión en proceso y la dimensión SKU adoptan el modelo de cadena de responsabilidad para el cálculo de montos para diferentes negocios.



6. Referencias

Mal olor a código: https://www.qinglite.cn/doc/87036476d565d55f9

"Refactorización para mejorar el diseño del código existente": [estadounidense] Martin Fowler

"Desarrollo de software ágil": [EE.UU.] Robert C.Martin

Autor: JD Retail Gao Kai

Fuente: Comunidad de desarrolladores de JD Cloud Indique la fuente al reimprimir

Alibaba Cloud sufrió un fallo grave y todos los productos se vieron afectados (restaurados). Tumblr enfrió el sistema operativo ruso Aurora OS 5.0. Se presentó la nueva interfaz de usuario Delphi 12 y C++ Builder 12, RAD Studio 12. Muchas empresas de Internet contratan urgentemente programadores de Hongmeng. Tiempo UNIX está a punto de entrar en la era de los 1.700 millones (ya entró). Meituan recluta tropas y planea desarrollar la aplicación del sistema Hongmeng. Amazon desarrolla un sistema operativo basado en Linux para deshacerse de la dependencia de Android de .NET 8 en Linux. El tamaño independiente es reducido en un 50%. Se lanza FFmpeg 6.1 "Heaviside"

{{o.nombre}}

{{m.nombre}}