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 la entrega a domicilio y las 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: Utilizar 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
Audacia: significa tener el coraje y la determinación de cambiar y mejorar el código existente. La refactorización puede implicar realizar cambios en estructuras de código complejas e incluso puede requerir reescribir partes del código. Los desarrolladores audaces están dispuestos a afrontar estos desafíos y creen que los cambios pueden conducir a mejores resultados.
Cuidadoso: se refiere a mantener pensamientos y acciones meticulosos al refactorizar. Esto incluye analizar cuidadosamente la estructura y la lógica del código, comprender la funcionalidad y las dependencias del código y considerar el impacto potencial que puede tener cada paso de refactorización. Los desarrolladores cuidadosos manejarán cuidadosamente cada detalle durante el proceso de refactorización para garantizar la corrección y la mantenibilidad del código.
-
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, poca legibilidad, mala mantenibilidad o mal gusto, y cuando el cronograma de demanda del proyecto no es ajustado, es A buen momento para refactorizar;
-
La clasificación temprana es muy importante
, encuentre primero los puntos débiles,
no es adecuado para operaciones a largo plazo
y no es adecuado para ejecutarse en paralelo con el negocio;
-
Aclare los objetivos y valores
:
los reembolsos posventa y la reconstrucción del cálculo de importes pueden mejorar la eficiencia del desarrollo, reducir los costos de mantenimiento y desarrollo, etc.;
-
Determine los objetivos de la refactorización
:
primero, identifique los bloques de código o funciones que deben refactorizarse y aclare cuáles son los objetivos de la refactorización.
Por ejemplo, puede ser necesario mejorar la legibilidad, el mantenimiento o el rendimiento del código;
-
Analizar olores de código
: utilice herramientas de análisis estático de código o verifique manualmente el código para identificar posibles
olores de 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 muchas duplicaciones en el reembolso. Código comercial y otros
olores de código
;
-
Elija técnicas de refactorización adecuadas
:
elija técnicas de refactorización adecuadas según los tipos de malos olores en el código posventa
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 supergrandes, 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;
-
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 diversas situaciones del bloque de código o función refactorizado;
-
Realizar refactorización
:
Modifica el código paso a paso según la técnica de refactorización elegida.
Asegúrese de que cada código modificado aún pase los casos de prueba escritos previamente;
-
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;
-
Evaluación del código después de la refactorización
:
evalúe si el código refactorizado logra los objetivos esperados, como si mejora 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 para mejorar; la disección 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
-
Reducir los costos de desarrollo y mantenimiento.
-
Mejorar la calidad del código y la estabilidad del sistema.
-
Escalabilidad y flexibilidad mejoradas del sistema;
-
Las aplicaciones del sistema y el posicionamiento de los límites comerciales se vuelven más claros
-
Unifique y estandarice el contexto empresarial central de posventa, reduzca los costos de aprendizaje empresarial y mejore la eficiencia del desarrollo.
-
Mejore sus capacidades técnicas, conocimiento 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.1、重构前金额计算
一个大的金额计算class类就有1000多行代码，每个方法中都有几百行代码，以下是到家售后单金额计算部分代码：
到家和京东售后单金额计算用同一个接口才承接业务实现，并且使用策略+抽象工厂模式实现到家、小时购、天选业务的金额计算。
其中金额计算的核心则采用的是责任链业务进行计算
在件维度、sku维度针对不同的业务又采用了责任链模式进行金额计算
参考资料
[1] 代码的坏味道：https://www.qinglite.cn/doc/87036476d565d55f9
[2] 《重构改善既有代码的设计》：
[美]MartinFowler
[3] 《敏捷软件开发》：[美]RobertC.Martin
-end-
本文分享自微信公众号 - 京东云开发者（JDT_Developers）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
