Des trucs hardcore : un voyage de reconstruction de plus de 30 000 lignes de code dans un système central

Il y a ce passage dans le livre classique "Refactoring" :

Au début, les refactorisations que je faisais étaient toutes une question de détails. À 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 refactorisation, je ne pourrais pas atteindre ce niveau.

Le refactoring est vraiment une chose passionnante pour les programmeurs.

Au début de cette année, notre équipe a achevé la reconstruction d'un projet complexe. Il s'agit de la partie centrale du moteur du système publicitaire, avec environ plus de 300 fichiers et plus de 30 000 lignes de code.

Cela n'a pris qu'environ 1 mois entre la conception de la solution technique et le lancement complet final, et il n'y a eu aucun accident.

Cela devrait être le projet de refactoring le plus important et le plus réussi que j'ai jamais connu au cours de mes 8 années de carrière en programmation : il est assez rapide, le plan est complet et la qualité est acceptable.

01 Parlons d'abord du bagage historique de ce système

Notre moteur publicitaire a connu des itérations pendant environ un an et demi avant cette reconstruction. Au début, il était ciblé sur des scénarios de recherche, avec un. une entreprise unique et des processus clairs.

À partir de 2019, l’activité publicitaire de l’entreprise a commencé à se développer rapidement, avec des revenus en croissance presque exponentielle. Au cours de ce processus, notre moteur publicitaire a été confronté à deux défis :

1. Les scénarios commerciaux ont commencé à devenir complexes. En plus de la publicité sur les recherches, il devait également prendre en charge les recommandations de flux d'informations et des scénarios de recommandations similaires.

2. Le trafic publicitaire commence à augmenter rapidement. En plus de répondre aux exigences fonctionnelles, il faut également prendre en compte les performances.

Après le tri, la majeure partie de la logique de l'ensemble du moteur peut être partagée, nous avons donc défini un cadre principal et résumé les parties extensibles. Ainsi, chaque scénario peut mettre en œuvre certaines interfaces publiques selon la particularité de son propre métier. De plus, du point de vue des performances, nous avons sacrifié une certaine lisibilité du code et parallélisé une certaine logique.

Avec le développement des affaires, le scénario de recherche a commencé à entrer dans une période d'itération rapide, avec de plus en plus de nouvelles stratégies ajoutées, et notre cadre principal est progressivement devenu inflexible à cette époque.

Si vous modifiez le cadre principal, les scènes autres que la recherche devront être reconstruites en conséquence. Pendant la période de développement rapide des affaires, le calendrier de construction n'est pas du tout autorisé, nous ne pouvons donc effectuer le développement de correctifs que sur le framework existant. Cela pose deux problèmes évidents :

1 Afin d'être compatible avec la logique particulière de recherche, nous devons ajouter divers jugements if dans d'autres scénarios pour contourner ces logiques.

2. Il existe de plus en plus de stratégies publicitaires, des dizaines au total. Lorsque le cadre perd sa structure claire, la mise en œuvre de certaines stratégies commence à devenir personnalisée, manquant de division hiérarchique et de conception abstraite enfichable.

Dans ce contexte, avec l'accumulation de changements, le code a commencé à s'écarter de l'intention initiale de la conception, et la dette technique est devenue de plus en plus lourde. Cependant, nous n’avons jamais pu trouver le bon moment pour refactoriser.

Le tournant s'est produit fin 2019. En raison de la particularité du secteur de la publicité, le trafic a commencé à diminuer naturellement. De plus, l'équipe des opérations produits s'est concentrée sur la planification du travail pour la deuxième année. , ce qui nous a beaucoup aidé. Une bonne période fenêtre pour démarrer cette reconstruction.

Nous avons fixé la période de construction à 1 mois, et au final n'était en ligne qu'un jour plus tard que prévu. Bien que deux problèmes en ligne se soient produits, ils ont été découverts et réparés à temps pendant la période en niveaux de gris, et aucun problème hors ligne. ont été provoqués.

En général, il s'agit d'un projet de refactoring difficile et relativement réussi. Parlons en détail de l'expérience précieuse que j'ai tirée de ce projet.

02 Quelles préparations avons-nous faites avant le refactoring ?

La quantité de code refactorisé cette fois est très importante, plus de 30 000 lignes, et c'est la partie centrale du moteur du système publicitaire. Avant le lancement, on peut s'attendre aux difficultés suivantes :

1 Résistance du côté des entreprises : La publicité est extrêmement orientée vers les affaires, même si cette restructuration peut apporter une efficacité R&D à long terme. ne peut pas améliorer directement les revenus de l'entreprise, et le cycle de développement ne sera pas trop court. Comment pouvons-nous obtenir le soutien des camarades de classe en commerce ?

2. Problèmes techniques : Une fois que la refactorisation provoque un accident en ligne, l'entreprise dispose d'un système de pénalités. Comment pouvons-nous laisser tout le monde se battre à la légère ? Dans le même temps, si des itérations commerciales très lourdes sont intercalées au cours du processus de reconstruction, personne ne peut garantir les délais de livraison et il sera difficile d'en contrôler la qualité.

En réponse aux préoccupations de ces deux parties, je pense que les tâches suivantes jouent un rôle clé.

▍Laissez tout le monde voir les points douloureux

Comme mentionné précédemment : avec l'itération commerciale, le cadre principal de notre moteur publicitaire est devenu flou et des dizaines de stratégies publicitaires sont dispersées dans différents scénarios commerciaux avec des configurations désordonnées.

En réponse à ces deux problèmes, nous avons commencé à trier les activités existantes un mois à l'avance, en lisant les anciens codes et en parcourant les documents d'exigences précédents. Enfin, nous avons classé les processus de base et les stratégies publicitaires des différents scénarios en un seul A. forme claire.

C'est ce tableau qui permet à la technologie et aux produits de voir clairement l'ensemble de notre pièce moteur pour la première fois, et de comprendre la complexité de l'entreprise et les goulots d'étranglement techniques actuels.

▍Après avoir clarifié les objectifs et les valeurs du refactoring

et fait ressentir à chacun les points douloureux, nous avons prévu deux objectifs principaux pour ce refactoring :

1. du cadre principal : modulariser le processus principal, redéfinir les protocoles des couches supérieure et inférieure et garantir des interfaces claires. Chaque niveau doit également être abstrait en interne et avoir une bonne évolutivité ;

2. Stratégies flexibles et configurables : les stratégies publicitaires sont classées et résumées en fonction des intentions commerciales, les conditions d'exécution des stratégies sont configurables de manière dynamique et les stratégies peuvent être branchées et déconnectées à volonté.

De plus, nous avons affiné les bénéfices attendus qui peuvent être apportés après avoir atteint ces deux objectifs fondamentaux :

1. Avantages techniques : la structure du code est plus claire, plus facile à comprendre et à maintenir ; l'évolutivité est améliorée et l'efficacité du développement du moteur sera encore améliorée.

2. Avantages commerciaux : les stratégies peuvent permettre une configuration et une expansion plus fines, et sont plus conviviales pour le support commercial ; une efficacité R&D améliorée peut accélérer davantage les itérations commerciales.

Après avoir synchronisé la valeur de la reconstruction pour tout le monde, cela augmente encore l'enthousiasme de chacun et donne à chacun une motivation plus forte à participer.

▍Le contrôle du rythme global

Le contrôle du rythme global est également un élément très important, permettant à chacun d'avoir une attente de temps en la matière.

Tout d'abord, nous avons fixé la durée de construction à 1 mois. D'une part, nous avons considéré le temps de cycle maximum acceptable du côté commercial, et nous espérions également une solution rapide sur le plan technique, d'autre part ; La Fête du Printemps approche et nous devons nous dépêcher avant la fermeture de l'entreprise. Connectez-vous avant de vous connecter et réservez un délai d'une à deux semaines pour éviter des situations inattendues.

De plus, nous avons conclu un accord avec le côté commercial : pendant la période de reconstruction, les exigences non urgentes concernant la pièce moteur ne seront pas acceptées. Cela peut minimiser le développement parallèle et les conflits de code et permettre à l'équipe de se concentrer davantage.

03 Quelles expériences pouvez-vous partager pendant le processus de mise en œuvre ?

Cette refactorisation a été mise en œuvre si facilement. J'ai 4 expériences précieuses à partager avec vous.

1. Solutions de conception technique de haute qualité

Nous concevrons des solutions techniques pour des projets avec un cycle de développement de plus de 3 jours. Cette reconstruction ne fait certainement pas exception.

L'architecture globale du framework, la conception du protocole entre les modules et la conception de l'évolutivité de la stratégie sont au centre de cette solution technique. L'équipe en a discuté pas moins de trois fois.

Une fois le grand plan finalisé, l'équipe a affiné davantage les parties publiques telles que la base de données, les champs d'interface, la structure du cache, les points enfouis dans les journaux, etc. Parce qu'il s'agit d'un développement collaboratif multi-personnes, l'équipe a accepté d'utiliser des documents comme l'interface de communication et les documents restent toujours synchronisés avec votre code.

Avec des exigences aussi élevées, l'équipe a produit un document de solution technique de plus de 5 000 mots, totalisant 36 pages, qui a jeté une bonne base pour l'assurance qualité globale.

2. Pré-refactoriser le code du framework

Ce PR est très critique et constitue l'étape la plus importante de la mise en œuvre de notre solution technique au code. Nous avons trié la structure du package reconstruite, la division des modules, la définition de l'API entre chaque couche et l'abstraction des différentes stratégies publicitaires, en ignorant d'abord les détails de mise en œuvre.

De cette façon, le code principal est essentiellement formé, qui peut clairement décrire notre cadre idéal. Nous avons ensuite organisé plusieurs revues de code centralisées et avons finalement formé une opinion unifiée.

Cette étape peut très bien éviter de se laisser entraîner prématurément dans les détails de mise en œuvre, ce qui entraînerait une attention insuffisante au framework principal et un code instable qui réduirait en fait l'efficacité.

3. Communication fréquente et mécanisme de révision du code couplé

Après être entré dans la phase de mise en œuvre détaillée, un point très important est : la compréhension de la logique existante. Le code moteur a été itéré pendant un an et demi. Il a été développé par de nombreuses personnes dans l'histoire, mais cette fois seuls trois étudiants ont participé à la reconstruction.

Pendant tout le processus, lorsque nous avons rencontré une logique de code peu claire, nous avons communiqué et vérifié à plusieurs reprises, et n'avons pas fait de suppositions subjectives. Cette mise en garde est en fait très importante.

De plus, pour la révision du code, nous avons confié à des étudiants connaissant ce métier la responsabilité de chaque module. Ils sont jumelés et le dispositif est flexible.

4. Plan de test efficace

La refactorisation n'a pas été effectuée, testez d'abord. Ce principe est souligné dans le livre « Refactoring » et est également au centre de notre discussion sur cette solution technique. Je le soulignerai ici pour le développer en détail.

Tout d'abord, nous avons conclu un accord dès le début : ne toucher à aucun ancien code et construire complètement un nouveau package pour la reconstruction. Cela facilite la comparaison des résultats avant et après la reconstruction et permet de mener simultanément des expériences en niveaux de gris en ligne.

Concernant le plan de test, les 4 points suivants méritent d'être appris :

1 Tests de bout en bout : Cette refactorisation n'implique pas d'ajustements fonctionnels, donc le comportement de l'extérieur. L'API ne le fera pas. S'il y a des changements, cette méthode de test de bout en bout est la plus efficace. Il s'agit du moyen le plus important de test de R&D et d'assurance qualité.

2. Test de fumée : Les étudiants en assurance qualité fournissent des cas de fumée et les étudiants en R&D effectuent le test de fumée. Avant le test de fumée, tous les cas de fumée doivent être réussis. Ce n'est pas courant dans la plupart des sociétés Internet, mais c'est absolument efficace pour les grands projets.

3. Vérification à double processus de l'environnement Sandbox : comme mentionné précédemment, le code avant et après notre reconstruction est conservé, de sorte que les paramètres d'entrée de l'environnement en ligne peuvent être capturés via des scripts sous forme de cas, puis les retours de l'API sont renvoyés. de manière automatisée. Les champs sont comparés un par un.

4. Expérience en niveaux de gris dans l'environnement en ligne : Les niveaux de gris sont très importants pour la reconstruction. Nous utilisons la plateforme ABTest existante pour libérer progressivement le trafic en niveaux de gris, de 5 %, à 10 %, à 30 % et enfin à 100 %. un rythme très prudent d'expansion des volumes a été établi, puis vérifié au moyen de journaux et de suivi d'indicateurs commerciaux.

Écrit à la fin

Revue de l'ensemble du processus de reconstruction, résumée dans les 7 points clés suivants :

1. Saisissez l'opportunité de restructurer

2. Le tri précoce est très important, trouvez d'abord les points faibles

3. Clarifiez les objectifs et les valeurs pour enthousiasmer tout le monde

4. ne convient pas aux opérations à long terme, il ne convient pas En parallèle avec les affaires

5 Des solutions techniques de haute qualité sont nécessaires

6 La refactorisation n'est pas encore terminée, testez d'abord

7. soigneusement et être responsable de chaque ligne de code

Bien sûr, le facteur le plus important, ce sont les personnes. La refactorisation de projets à grande échelle met extrêmement à l'épreuve la capacité de collaboration de l'équipe. Si tout le monde est fiable, la refactorisation sera à moitié réussie. .

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!