1. Reconstruire l'arrière-plan
1.1. Remboursement
Il existe deux structures pour la livraison à domicile, l'achat horaire et le remboursement Tianxuan, et la logique du code prête à confusion ;
Parmi eux, certaines commandes après-vente pour l'achat horaire et Tianxuan sont remboursées de manière interactive avec Hepingsheng pop, et certaines sont remboursées de manière interactive avec le centre après-vente, et sont compatibles avec 3 ensembles de logiques ;
Points faibles
: code lourd, manque de conception rationnelle, coûts de développement et de maintenance itératifs ultérieurs élevés, risques et instabilité accrus du système.
1.2. Calcul du montant
Il existe deux ensembles indépendants de calculs de structure logique pour la livraison à domicile et les achats horaires.Sur cette base, deux ensembles de logiques sont mis en œuvre pour le remboursement et le non-remboursement ;
Le calcul du montant pour la dimension des pièces de produit, la dimension de la ligne de produits et la dimension unique du service après-vente prête à confusion, et il y a un manque de limites de domaine et de conception hiérarchique ;
Points faibles
: le calcul des montants dans la dimension unique après-vente, la dimension de la ligne de produits et la dimension des pièces divisées est source de confusion, et le code manque de structure hiérarchique ; il existe des problèmes de lisibilité du code, de coûts de maintenance et d'évolutivité ultérieure.
1.3. Compte inversé après-vente
L'interface des détails de la commande après-vente et l'interface des détails de la commande en cas de réclamation ont deux ensembles de logiques pour la livraison à domicile et l'achat horaire ;
Parmi eux, l'interface des détails de la commande après-vente dispose de 5 ensembles de traitements logiques pour la liste noire d'achat horaire, la liste blanche d'achat horaire, Tianxuan, le remboursement à domicile et le non-remboursement à domicile ;
De plus, ces deux interfaces obtiennent le montant du fractionnement en temps réel pour le calcul du fractionnement inversé après-vente, et peuvent directement obtenir et attribuer des valeurs à partir de la base de données, sans avoir besoin d'un calcul de fractionnement après-vente unidimensionnel ;
Points faibles
: une grande redondance du code, des coûts de modification élevés, des risques et une instabilité accrus du système
2. Idées et plans de reconstruction
2.1. Idées de reconstruction
Qu’est-ce que la refactorisation ?
Nom : Un ajustement de la structure interne d'un logiciel dans le but d'améliorer sa compréhensibilité et de réduire ses coûts de modification sans modifier le comportement observé du logiciel ;
Verbe : Utiliser une série de techniques pour ajuster la structure du logiciel sans modifier son comportement observable.
Le but de la refactorisation est de rendre le système ou le code plus facile à comprendre, à modifier et à itérer.
Le secret de la refactorisation : soyez audacieux et prudent
L’audace : c’est avoir le courage et la détermination de changer et d’améliorer le code existant. La refactorisation peut impliquer d'apporter des modifications à des structures de code complexes et peut même nécessiter la réécriture de parties du code. Les développeurs audacieux sont prêts à relever ces défis, convaincus que les changements peuvent conduire à de meilleurs résultats.
Attention : fait référence au maintien d'une réflexion et d'actions méticuleuses lors de la refactorisation. Cela implique d'analyser soigneusement la structure et la logique du code, de comprendre les fonctionnalités et les dépendances du code et de considérer l'impact potentiel que chaque étape de refactorisation peut avoir. Les développeurs attentifs traiteront soigneusement chaque détail pendant le processus de refactorisation pour garantir l'exactitude et la maintenabilité du code.
-
Saisir l'opportunité de refactoriser
: Quand je constate que le code des modules métiers tels que les remboursements après-vente et le calcul des montants présente des problèmes de qualité, une mauvaise lisibilité, une mauvaise maintenabilité ou un mauvais goût, et que le calendrier de demande du projet n'est pas serré, c'est A bon moment pour refactoriser ;
-
Le tri précoce est très important
, trouvez d'abord les points faibles,
il ne convient pas aux opérations à long terme
et il ne convient pas de fonctionner en parallèle avec l'entreprise ;
-
Clarifier les objectifs et les valeurs
:
les remboursements après-vente et la reconstruction du calcul du montant peuvent améliorer l'efficacité du développement, réduire les coûts de maintenance et de développement, etc. ;
-
Déterminer les objectifs du refactoring
:
Tout d’abord, identifiez les blocs de code ou les fonctions qui doivent être refactorisés et clarifiez quels sont les objectifs du refactoring.
Par exemple, il peut s'avérer nécessaire d'améliorer la lisibilité, la maintenabilité ou les performances du code ;
-
Analyser les odeurs de code
: Utilisez des outils d'analyse statique du code ou vérifiez manuellement le code pour identifier d'éventuelles
odeurs de code
; par exemple, il y a plus de 1 000 lignes de classes, plus de 600 lignes de méthodes, trop de paramètres variables et de nombreuses duplications dans le remboursement. Code des affaires et autres
odeurs de code
;
-
Choisissez des techniques de refactoring appropriées
:
Choisissez des techniques de refactoring appropriées en fonction des types de mauvaises odeurs dans le code après-vente
Les techniques de refactoring que j'utilise sont : refactoring à petite échelle -> refactoring à grande échelle -> modèle de conception de haut niveau ; j'utilise l'idée de d'abord petit puis grand, et de grand à complet pour refactoriser la conception. . Refactoring à petite échelle : extraire des méthodes, éliminer des classes ou des méthodes de fonction très volumineuses, extraire des classes, renommer, fusionner du code en double, etc. ; refactoring à grande échelle : adopter la superposition, la modularisation, le découplage, la réutilisabilité abstraite, etc. Technique ; Modèle de conception : L'entreprise de remboursement adopte le modèle de stratégie + usine abstraite, l'entreprise de calcul des montants adopte le modèle de stratégie + usine abstraite + modèle de chaîne de responsabilité.
-
Écrire des cas de test
:
avant de refactoriser, écrivez des cas de test appropriés pour vérifier l'exactitude du code refactorisé.
Les cas de test doivent couvrir diverses situations du bloc de code ou de la fonction refactorisé ;
-
Effectuer un refactoring
:
Modifiez le code étape par étape selon la technique de refactoring choisie.
S'assurer que chaque code modifié réussit toujours les cas de tests précédemment écrits ;
-
Exécuter des cas de test
:
après chaque refactorisation, exécutez les cas de test précédemment écrits pour vous assurer que le code refactorisé est toujours correct ;
-
Évaluation du code après refactorisation
:
évaluez si le code refactorisé atteint les objectifs attendus, par exemple s'il améliore la lisibilité, la maintenabilité ou les performances du code.
2.2. Plan de reconstruction
2.2.1. Schéma d'interaction système avant reconstruction
2.2.2. Diagramme d'interaction du système après reconstruction
L'activité de remboursement est fortement couplée au système après-vente et le code commercial est dispersé dans différentes couches commerciales. Il existe un manque sérieux de limites de domaine et de conception hiérarchique du système. Après la reconstruction, la logique métier de remboursement ne s'appuie pas beaucoup sur la logique métier de base de l'après-vente et peut être déployé de manière indépendante.
2.2.3. Organigramme de calcul du montant avant reconstruction
2.2.4. Organigramme de calcul du montant après reconstruction
Utilisez des modèles de conception pour fusionner deux ensembles de logique métier de calcul de montant en un seul ensemble de logique métier de calcul de montant afin de créer une couche anticorrosion.
2.3. Reconstruire le diagramme de classe de conception
Sur la base de l'organigramme de conception formulé ci-dessus, j'ai dessiné un diagramme de classes UML. Ce qui suit est un diagramme de classes pour le module métier de calcul de montant.
2.3.1. Diagramme de classes d'usine abstraite + modèle de stratégie
2.3.2. Diagramme de classes du modèle de chaîne de responsabilité
3. Garantie de stabilité du système
3.1. La reconstruction par petites étapes
Divisez la reconstruction après-vente en trois étapes : remboursement, calcul du montant et comptabilité inversée, et exécutez des scénarios de test après chaque étape. Cela permet de découvrir et de corriger les erreurs introduites en temps opportun, empêchant ainsi leur propagation dans tout le système.
3.2. Vérification étape par étape
Après chaque étape de refactorisation, effectuez une vérification étape par étape du système. Les niveaux de gris sont lancés par lots. Les configurations en niveaux de gris sont absolument isolées et ne peuvent pas être réutilisées. Assurez-vous que les différentes parties du système fonctionnent correctement et se coordonnent bien avec les autres parties pendant le processus de refactorisation.
3.3. Surveillance et tests de performances
Une fois la refactorisation terminée, effectuez une surveillance du système et des tests de performances pour vous assurer que la refactorisation n'introduit pas de problèmes de performances ou n'affecte pas la stabilité du système. Si des problèmes sont détectés, réparez-les et optimisez-les à temps.
3.4. Examen et tests du code de l'équipe
Collaborez avec les membres de l'équipe et effectuez des révisions de code lors de la refactorisation. Les points de vue et les expériences de plusieurs personnes peuvent aider à découvrir des problèmes potentiels et fournir des suggestions d'amélioration ; une analyse approfondie du code refactorisé peut garantir plus efficacement la sécurité du refactoring.
L'entreprise de refactoring informe les testeurs en temps opportun, afin que ceux-ci puissent évaluer les points de test et améliorer les cas de test.
3.5. Étapes en niveaux de gris
3.5.1, comparaison et vérification continue bcp
3.5.2. Selon les niveaux de gris du marchand
Effectuez progressivement une découpe en niveaux de gris selon l'ordre des petites -> moyennes -> grandes commandes après-vente, et observez si les données de la commande après-vente telles que le remboursement et le calcul du montant sont anormales.
4. Résultats de la reconstruction
-
Réduire les coûts de développement et de maintenance
-
Améliorer la qualité du code et la stabilité du système
-
Évolutivité et flexibilité améliorées du système ;
-
Les applications système et le positionnement des limites commerciales deviennent plus clairs
-
Unifiez et standardisez le contexte commercial de base du service après-vente, réduisez les coûts de formation commerciale et améliorez l'efficacité du développement.
-
Améliorez vos capacités techniques, votre conscience de la qualité du code, vos compétences en résolution de problèmes, votre travail d'équipe et vos compétences en communication ;
il y a un passage dans le livre classique "Refactoring" :
Au début, la refactorisation que j'ai effectuée était axée sur les détails. Au fur et à mesure que le code devient plus concis, je constate que je peux voir certaines choses au niveau de la conception que je ne pouvais pas comprendre auparavant. Sans refactoring, je ne pourrais pas atteindre ce niveau.
5.1、重构前金额计算
一个大的金额计算class类就有1000多行代码，每个方法中都有几百行代码，以下是到家售后单金额计算部分代码：
到家和京东售后单金额计算用同一个接口才承接业务实现，并且使用策略+抽象工厂模式实现到家、小时购、天选业务的金额计算。
其中金额计算的核心则采用的是责任链业务进行计算
在件维度、sku维度针对不同的业务又采用了责任链模式进行金额计算
参考资料
[1] 代码的坏味道：https://www.qinglite.cn/doc/87036476d565d55f9
[2] 《重构改善既有代码的设计》：
[美]MartinFowler
[3] 《敏捷软件开发》：[美]RobertC.Martin
-end-
本文分享自微信公众号 - 京东云开发者（JDT_Developers）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
