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.
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.
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.
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.
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 ?
▍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.
▍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.
03 Quelles expériences pouvez-vous partager pendant le processus de mise en œuvre ?
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.
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 :
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!