🔴 👇🏻 🐫 Méthodes de traitement du code hérité en utilisant GitLab comme exemple 👨🏽‍🏭 💐 ✌🏽

Vous pouvez sans cesse tricher si GitLab est un bon produit. Il vaut mieux regarder les chiffres: selon les résultats du cycle d'investissement, la valorisation de GitLab était de 2,7 milliards de dollars, tandis que la valorisation précédente était de 1,1 milliard de dollars. Cela signifie une croissance rapide et la société embauchera de plus en plus de développeurs front-end.

C'est l'histoire de l'apparition du frontend dans GitLab.

Il s'agit d'un graphique du nombre de fournisseurs frontaux dans GitLab, commençant en 2016, quand ils n'étaient pas là du tout, et se terminant en 2019, alors qu'il y en avait déjà quelques dizaines. Mais GitLab lui-même existe depuis 7 ans. Donc, jusqu'en 2017, le code principal sur le frontend a été écrit par les développeurs du backend, pire, les développeurs du backend sur Ruby on Rails (en aucun cas, nous ne voulons offenser qui que ce soit et expliquer ci-dessous de quoi nous parlons).

Depuis 7 ans, tout projet, qu'il vous plaise ou non, devient obsolète. À un moment donné, le refactoring devient impossible à reporter. Et le voyage commence, plein d'aventures, dont le point final n'atteint jamais. À propos de la façon dont cela se produit dans GitLab, a déclaré Ilya Klimov.

À propos de l'orateur: Ilya Klimov (xanf) ingénieur frontend senior chez GitLab. Avant cela, il a travaillé dans des startups et de l'externalisation, a dirigé une petite entreprise d'externalisation. Ensuite, j'ai réalisé que je n'avais pas encore eu le temps de travailler sur le produit et je suis venu à GitLab.

L’article est basé sur un rapport d’Ilya de FrontendConf . Par conséquent, il ne structure pas tant les informations que l’expérience de l’orateur. Cela peut sembler excessivement conversationnel, mais non moins intéressant du point de vue du travail avec l'héritage.

Dans GitLab, comme dans de nombreux autres projets, ils migrent progressivement des anciennes technologies vers quelque chose de plus pertinent:

CoffeeScript en JavaScript. Les développeurs de Ruby on Rails, lorsqu'ils ont commencé le projet, ne pouvaient s'empêcher de prêter attention à CoffeeScript, qui ressemble beaucoup à Ruby.
JQuery Vue. , JQuery. GitLab SPA. server-side rendering progressive enhancement, Vue-. , : Vue-, .
Karma Jest. Jest - . Karma , , .
REST GraphQL , , Vuex Apollo. Vuex, Redux Vue, Apollo local state , . GraphQL , .

En même temps, les remplacements ont lieu dans plusieurs directions à la fois, dans le projet il y a simultanément un code hérité à différentes étapes.

Imaginez maintenant que vous arrivez à un projet au milieu de toutes ces migrations. Le point standard et de référence pour moi était la situation lorsque vous ouvrez l'édition d'un projet, appuyez sur le bouton Enregistrer - et que pensez-vous qui s'en vient? Si vous pensiez que nous sommes de tels vieux phages que HTML vient, alors non. JavaScript vient du fait que vous devez «évoluer» pour afficher une fenêtre pop-up. C'est le point bas de ma photo héritée.

Plus loin: des classes auto-écrites dans JQuery, des composants Vue et, comme point culminant, de nouvelles fonctionnalités modernes écrites avec Vuex, Apollo, Jest, etc.

Voici à quoi ressemble mon graphique de contribution sur GitLab.

Dans ce document - et cela est très important pour comprendre l'essence de l'histoire et toutes mes douleurs - plusieurs segments peuvent être distingués:

Intégration dans la zone avril. «Lune de miel» quand je viens de commencer à travailler chez GitLab. À ce moment, les débutants se voient confier des tâches plus faciles.
De la fin avril à la mi-mai, il n'y a que quelques commits - une période de déni : «Non, il ne peut pas que tout se fasse de cette façon!» J'ai essayé de comprendre où je ne comprenais pas quelque chose, donc il y a si peu de commits.
La deuxième moitié de mai est la colère : "Je m'en fous de tout - j'ai besoin de déplacer la production, de partager des fonctionnalités, d'essayer de faire quelque chose."
Le début de juin (zéro engagement) est une dépression . Ce n'était pas des vacances, j'ai regardé et compris que mes mains tombaient, je ne sais pas quoi en faire.
Après cela, je suis d' accord avec moi - même , j'ai décidé d'être embauché en tant que professionnel et je peux améliorer GitLab. En juin et juillet, j'ai proposé un grand nombre d'améliorations. Tous n'ont pas résonné pour des raisons dont nous parlerons.
Maintenant, je suis au stade de l' adoption et je comprends clairement: comment, où, pourquoi et quoi faire avec tout cela.

Je vais vous dire plus en détail ce que j'ai fait d'août à octobre. Honnêtement, dans une petite entreprise d'externalisation ou dans une startup, j'aurais été licencié cinq fois avec une telle productivité en trois mois.

Donc, en trois mois, j'ai fait:

Contrôle segmenté - trois boutons.
La chaîne de recherche qui stocke l'historique local est un composant légèrement plus complexe.
Fileur. Et ce composant n'est pas encore figé.

Ensuite, étape par étape, nous analyserons pourquoi cela s'est produit et comment vivre avec. S'il vous semble que j'exagère, voici une capture d'écran de certaines des tâches qui m'accrochent sur GitLab (vous pouvez regarder directement GitLab, il est ouvert).

Voir: manqué 12,1, manqué 12,2, manqué 12,3. Le sprint dure un mois et le contrôle segmenté - 3 sprints. Spinner est toujours parti, il sera notre personnage principal.

Le problème du refactoring et la philosophie du refactoring sont confrontés à l'humanité depuis très longtemps - depuis des millénaires. Je vais maintenant prouver:

« ; , , ; ; , .

, , , : ».

La Bible nous explique comment combiner des fonctionnalités anciennes et nouvelles. La deuxième partie de la citation est précieuse du point de vue du management: peu importe comment vous sortez avec les initiatives, vous rencontrerez une grande résistance.

Dans la phase de dépression, j'ai regardé beaucoup de rapports sur la refactorisation de grands projets, mais environ 70% d'entre eux me rappelaient une blague.

Discussion Javist:
- Comment accélérer notre application Java?
- Oh, j'ai donc eu un rapport à ce sujet! Tu veux dire?
- Pour dire et je peux, j'accélérerais!

Si vous décidez toujours de vous lancer dans la voie dangereuse et fragile du refactoring, j'ai quelques recettes simples que j'ai développées pour moi et qui fonctionnent dans des conditions proches de la réalité.

1. Isolation

Pour accélérer les choses, améliorer, refactoriser, vous devez couper l'éléphant en steaks, c'est-à-dire diviser la tâche en plusieurs parties. GitLab est très grand, nous avons une chaîne Slack "Est-ce connu", où les gens posent des questions comme "Est-ce un bug ou une fonctionnalité, qui peut expliquer?" - et la réponse n'est pas toujours trouvée.

Un exemple simple: des captures d'écran du même endroit dans GitLab, prises avec une différence d'un jour.

J'étais très contrarié, parce que je travaillais sur ce bouton, et c'est tout ou partie des problèmes avec le bouton.

Qu'est-il arrivé? C'est simple: nous développons un système de conception, et dans le cadre d'un outil de livre d'histoire distinct pour tester un système de conception, nous avons désactivé le CSS GitLab global pour vérifier comment les composants CSS sont isolés du CSS global.

Résumé: CSS n'est plus sauvegardéau moins dans GitLab.

Je travaille avec JavaScript depuis 14 ans et je n'ai jamais vu de projet dont la durée d'au moins un an ou deux préserve le CSS entièrement géré. Soit dit en passant, le HTML ne peut pas non plus être enregistré (dans GitLab à coup sûr).

GitLab a été développé depuis longtemps et backendov. Ils ont pris la décision controversée d'utiliser Bootstrap car Bootstrap offrait un système de mise en page convivial.

Mais qu'est-ce que Bootstrap en termes de philosophie d'isolation des composants? Il s'agit d'environ 600 à 700 classes globales (en fait, chaque classe CSS est globale) qui imprègnent toute l'application. En termes de gérabilité, rien de bon n'en sortira.

La prochaine action (ne l'appelons pas une erreur) - GitLab a pris Vue.js. Le choix était raisonnable, en raison des trois cadres, c'est Vue qui vous permet de réécrire le plus facilement possible. Vous n'avez pas besoin de jeter et de couper immédiatement une grande application monopage, mais vous pouvez réécrire des petits nœuds individuels. Maintenant, cela peut être fait sur Angular, mais il y a 3-4 ans, quand Angular 2 est apparu, il ne pouvait pas coexister sur une page dans plus d'une instance. React est également possible maintenant, mais toute cette magie avec l'absence d'une étape de construction et ainsi de suite a fait pencher la balance vers Vue.

En conséquence, un mal a été combiné avec le second. C'est mauvais, car les styles Bootstrap ne savent rien du système de composants, et les composants Vue ont été écrits au début, de toute façon. Par conséquent, une décision volontariste a été prise de créer leur propre système de conception. Nous l'avons appeléPyjama , mais personne ne pouvait m'expliquer pourquoi.

Je vois que maintenant il y a de plus en plus de nos propres systèmes de conception, et c'est bien.

Le système de conception implique l'isolement, mais puisque GitLab a déjà été écrit en Bootstrap, environ 50 à 60% de notre système de conception est un wrapper sur les composants Bootstrap / Vue avec une diminution de leur fonctionnalité. Cela est nécessaire pour que le système de conception ne vous permette pas d'utiliser le composant de manière incorrecte. Si nous parlons d'une bibliothèque abstraite, la flexibilité y est importante, par exemple, la possibilité de créer n'importe quel bouton de votre choix. Si, dans GitLab, les filateurs peuvent avoir quatre tailles approuvées par les concepteurs, vous devez physiquement ne pas laisser les autres le faire.

Un jour, le bien gagnera, et nous aurons un outil important avec lequel, bien sûr, si vous avez marqué sur le support d'IE et Edge, vous pouvez efficacement refactoriser les projets frontaux - c'est Shadow DOM . Le Shadow DOM résout le problème des styles globaux coulant dans les composants. Veuillez ne pas prendre Polymer, que même Google a déjà enterré. Utilisez lit-element et lit-HTML, et vous pouvez créer des styles isolés en utilisant votre framework préféré.

Vous pouvez dire que React a des modules CSS, Vue a des styles étendus qui font de même. Soyez très prudent avec eux: les modules CSS ne fournissent pas une isolation à 100% car ils ne fonctionnent qu'avec des classes. Et avec les styles étendus dans Vue, un scénario très intéressant peut être réalisé lorsque les styles du composant supérieur tombent dans l'élément racine du parent et que des attributs de données sont utilisés qui ralentissent.

Malgré le fait que j'ai grondé Angular pendant trois ans, maintenant je dois admettre qu'au moment où il est le mieux implémenté. Dans Angular, afin d'assurer une bonne isolation de style, il suffit de changer simplement le mode d'isolement et, si nécessaire, d'utiliser le Shadow DOM, sinon une émulation normale.

Revenons au spinner. Des trois mois que j'ai combattus avec lui, j'ai été engagé pendant un certain temps dans une entreprise passionnante: le nettoyage.

Une classe loading-containerest un détail d'implémentation d'un spinner, c'est-à-dire qu'il s'agit d'une classe à l'intérieur d'une implémentation spinner. Nous avons décidé, puisque le CSS ne devait pas être enregistré, en pyjama de créer un CSS séparé basé sur le CSS atomique. Personnellement, je n'aime pas vraiment le concept CSS atomique, mais nous avons ce que nous avons.

Autrement dit, je me suis engagé à nettoyer les styles dans le code du produit principal qui étaient accrochés à des éléments qui sont des détails d'implémentation. Tout cela semble très simple - car, bien sûr, il existe des tests dans GitLab.

2. Tests

Les tests dans GitLab couvrent tout le code , assurent la fiabilité. Et donc le pipeline est terminé en 98 minutes.

GitLab collecte 40% du temps des coureurs publics sur GitLab.com car GitLab collecte des pipelines pour chaque demande de fusion.

J'étais très inspiré: j'ai finalement pu réaliser un projet où tout est couvert par des tests! La couverture du code backend est proche de 100%, et le code frontal au moment de mon arrivée était couvert par 89,3%.

Malheureusement, il s'est avéré que la plupart de cette couverture est une corbeille parce que:

tombe en panne lorsque des modifications ne sont pas liées aux composants;
Ne se casse pas lorsque des modifications sont apportées.

Je vais expliquer avec des exemples. Nous avons pris Jest parce que nous pensions qu'il nous permettrait dans certaines situations de ne pas écrire d'assertions, mais d'utiliser des instantanés. Le problème est que si vous n'avez pas configuré Jest et ajouté le sérialiseur correct, Vue Test Utils affiche simplement les accessoires en HTML. Ensuite, par exemple, il s'avère que les accessoires avec l'utilisateur de nom, qui avait des accessoires dans les paramètres avec les données de nom, auxquels l'objet objet a été transmis. Toute modification du format des données transmises n'entraîne pas l'échec de l'instantané.

Les développeurs Ruby ont l'habitude de faire des tests, grosso modo, couvrant toutes les méthodes.

Lorsque nous effectuons des tests pour les composants Vue ou React, nous devons tester le comportement de l'API publique.

Ainsi, nous avons eu d'énormes tests sur des propriétés calculées qui n'étaient pas utilisées dans certains scénarios, mais dans d'autres, il était physiquement impossible d'atteindre l'état où ce calcul serait appelé. Un merci spécial à Vue, dans lequel les modèles sont des chaînes, vous ne pouvez donc pas calculer la couverture de test du modèle. Dans Vue 3, les cartes sources apparaîtront et la possibilité de le réparer, mais ce ne sera pas pour bientôt.

Heureusement, il existe une compétence simple qui vous permettra de remanier efficacement l'héritage. C'est la capacité d'écrire ce qu'on appelle le test d'épinglage dans le monde des gros tests.

Test d'épinglage

Il s'agit d'un test qui tente de capturer le comportement que vous refactorisez. Veuillez noter que le test d'épinglage ne finira probablement pas par être validé dans le référentiel. Autrement dit, vous, à travers toutes sortes de raffinements, par exemple, en utilisant l'environnement de transfert, écrivez vous-même un test qui décrit comment votre composant est rendu. Après refactorisation, le test d'épinglage doit soit générer le même HTML, ce qui est très probablement un bon signe, soit comprendre les changements qui se sont produits.

Je vais donner un exemple tiré de la vie. Il y a quelques mois, j'ai effectué un examen de la demande de fusion avec la refactorisation d'une liste déroulante. Le contexte hérité est le suivant: auparavant, afin de séparer les branches d'un ami les unes des autres par un tiret dans la liste déroulante, la chaîne de texte «diviseur» était simplement passée. Par conséquent, si votre branche s'appelait diviseur, vous n'avez pas de chance. Dans le processus de refactoring, une personne a échangé deux classes dans un nœud HTML, cela est entré en production et l'a ruiné. En toute justice, bien sûr, pas tout à fait en production, mais en mise en scène, mais néanmoins.

Par conséquent, lorsque nous avons commencé à écrire de tels tests, nous avons constaté que, malgré l'indicateur de couverture de test sympa, les tests étaient mal écrits. Parce que, premièrement, nous avons eu des tests pour Karma, c'est-à-dire d'anciens. Deuxièmement, presque tous les tests ont émis des hypothèses sur les composants internes du composant. Autrement dit, ils prétendaient être des tests unitaires et fonctionnaient essentiellement comme de bout en bout, vérifiant qu'une balise spécifique avec une classe spécifique était en cours de rendu, au lieu de vérifier qu'un composant spécifique était rendu avec des accessoires spécifiques. Comprenez la différence: les classes sont des composants?

En conséquence, mes 18 demandes de fusion avec des tests de refactoring pour un total de 8 à 9 000 lignes, le changelog total s'est avéré être d'environ 20 000, car 11 000 ont été supprimés.

Dans le même temps, formellement, j'ai retravaillé tous ces tests pour une seule chose: supprimer les assertions concernant les classes de spinner et vérifier à la place que le spinner avec les accessoires corrects y est rendu.

À première vue, c'est un travail ingrat. Mais réécrire les tests pour la bonne architecture était assez facile à vendre à l'entreprise. GitLab est un produit commercialement rentable. Bien sûr, si vous dites au chef de produit que vous avez besoin de trois itérations pour réécrire 20 tests, devinez où vous serez envoyé. Autre chose: «J'ai besoin de trois itérations pour réécrire le test. Cela nous permettra de présenter les filateurs plus efficacement et d'accélérer la future mise en œuvre de nouveaux éléments du système de conception. » Et nous arrivons ici à l'important.

3. Résistance

Il y a une autre fonctionnalité que plus de mes filateurs attendent dans le système de conception GitLab - ce sont des icônes SVG ordinaires.

Nous avons des icônes dessinées par le designer qui sont utilisées dans le projet principal, mais elles ne sont pas dans le système de conception, car GitLab a une enfance difficile. Par exemple, en 2019, le CSS n'est pas collecté via Webpack, mais par un morceau appelé Sprockets - c'est le pipeline Ruby, car nous devons réutiliser le même CSS sur le backend et le frontend. Pour cette raison, les icônes doivent être connectées à différents projets de différentes manières. Par conséquent, quelqu'un a refactorisé la base de code principale pendant trois mois afin que vous puissiez connecter les icônes du système de conception aux projets associés.

Il y a ici un point important que vous rencontrerez inévitablement. Le refactoring est un processus d'amélioration continue. Mais tôt ou tard, vous devez vous arrêter.

Il est tout à fait normal de s'arrêter sans terminer la refactorisation, mais obtenir des améliorations concrètes et mesurables.

Mais si vous travaillez sur un projet hérité, vous rencontrerez inévitablement des gens qui le font.

Cela signifie qu'ils écrivent à l'ancienne, car ils y sont tellement habitués. Par exemple, nos bailleurs de fonds disent: "Je ne veux pas enseigner ceci à votre plaisanterie. J'ai écrit des tests pour Karma pendant trois ans, j'ai besoin d'ajouter de nouvelles fonctionnalités, et comme ils ne prendront pas de fonctionnalités sans tests, voici un test pour Karma. "

Votre tâche consiste à y résister autant que possible. C'est relativement facile à combattre, mais il y a un péché encore plus grand que cela. Parfois, dans le processus de refactorisation, vous rencontrez un problème et vous souhaitez généralement vous écarter.

Autrement dit, pour remplacer une nouvelle béquille simplement parce que pour certaines raisons, il n'est pas possible de mettre fin au refactoring. Par exemple, si nous avons des problèmes pour intégrer des icônes dans la base de code principale, nous pouvons laisser une classe utilitaire qui sera extraite du CSS d'application global. Formellement, la tâche commerciale sera résolue, mais dans la pratique, comme dans l'histoire de l'hydre lernéenne: il y avait 8 bugs, 4 corrigés, 13 restaient.

La refactorisation, comme la réparation d'une maison - il est impossible de terminer, vous ne pouvez que l'arrêter.

Les premiers 80% du refactoring prennent 20% du temps, les 80% restants du refactoring (juste comme ça) prennent encore 80% du temps.

Il est important de ne pas introduire de nouveaux hacks lors du processus de refactoring. Croyez-moi, au cours du processus de développement, ils apparaîtront eux-mêmes.

4. Outils

Heureusement, avant même mon arrivée, GitLab s'est engagé sur la bonne voie pour introduire de bons outils: Prettier, Vue Test Utils, Jest. Bien que Prettier l'ait implémenté de façon tordue.

Je vais vous expliquer ce qui est en jeu. Alors que j'ai compris quoi et pourquoi, historiquement, 80% de mes recherches sont tombées sur un commit de 37 000 lignes de code prettify. Il était presque impossible d'utiliser l'historique, et j'ai dû configurer le plug-in pour VS Code afin d'exclure ce commit lors de la recherche de l'historique des modifications.

Bien sûr, les outils sont importants, mais vous devez les choisir avec soin. Par exemple, nous avons Vue, et Vue a un bon outil de test - Vue Test Utils. Mais si Vue 2 est sorti il y a 2-3 ans, Vue Test Utils n'est toujours pas sorti de la version bêta. De plus, selon des informations privilégiées, à l'heure actuelle, le seul développeur de Vue Test Utils n'écrit pas sur Vue.

Dans le processus de choix des outils, vous jouez au sort et tentez vraiment de gagner.

GitLab a eu une blessure d'enfance avec CoffeeScript. C'est pourquoi il est impossible de pousser même l'idée théorique d'écrire en TypeScript dans GitLab. Tout se décompose en un argument simple: ne sera-t-il pas le même qu'avec CoffeeScript lorsque le langage qui se compile en JavaScript est mort.

Lors du choix des outils, essayez de remplacer l'outil ou, dans les cas extrêmes, de le maintenir indépendamment.

Chez GitLab, nous utilisons une chose cool appelée Danger.

Il s'agit d'une véritable capture d'écran de leur site Web en 2019. Mais, des collègues ont déclaré qu'en fait, en 2019, le site pourrait ressembler à n'importe quoi.

Le danger est un bot qui occupe un état intermédiaire entre le linter de votre CI et les directives écrites. Ce bot peut être développé et il viendra pour tirer la demande ou, comme ils sont correctement appelés avec nous, fusionner la demande et laisser des commentaires comme:

"Il y a un commentaire de désactivation ESlint dans ce fichier, corrigez-le."
«Ce fichier était auparavant dirigé par cette personne. Vous devrez peut-être y mettre un avis. »

À mon avis, c'est un très bon cadre, important et extensible pour surveiller l'état de la base de code.

5. Abstraction

Je vais commencer par un exemple. Il y a quelques mois, j'ai vu la nouvelle: «GitHub s'est débarrassé de jQuery. Nous avons parcouru un long chemin et n'utilisons plus jQuery. » Naturellement, je pensais que nous devions également nous débarrasser de jQuery dans GitLab.

Une recherche rapide a montré que jQuery est utilisé dans 300 fichiers. Cela semble effrayant, mais rien - les yeux ont peur, les mains font. Mais non! jQuery est une colle intégrale dans la base de code GitLab, car nous avons Bootstrap.

Bootstrap a été initialement écrit dans jQuery. Cela signifie que si vous devez, par exemple, intercepter l'événement d'ouverture déroulante dans Bootstrap, il s'agit d'un événement jQuery. Vous ne pouvez pas l'intercepter nativement.

C'est la première chose que vous devez abstraire lorsque vous travaillez avec du code hérité. Si vous avez jQuery que vous ne pouvez pas jeter, écrivez votre propre émetteur d'événements, qui se cachera à l'intérieur du travail avec les événements jQuery.

Lorsqu'un avenir radieux arrive, nous pouvons supprimer jQuery, mais pour l'instant, désolé, vous devez concentrer le govnokod. Dans un projet hérité régulier, il est réparti uniformément dans tout le code. Récupérez-le dans des goulots d'étranglement marqués des drapeaux «N'entrez pas sans combinaison de protection chimique».

6. Mesures

Vous ne pouvez pas faire quelque chose dont le résultat ne peut pas être mesuré. Chez GitLab, nous mesurons tout ce que nous faisons pour savoir objectivement que le code fonctionne mieux.

Par exemple, nous avons un calendrier de migration des tests Karma (bleu) vers Jest (vert):

vous voyez qu'il y a des progrès graduels. Et nous avons beaucoup de tels horaires. Mais il est important de comprendre que tout ne se termine pas toujours bien.

Je vais vous donner un autre exemple (la démo dans le rapport commence à partir de ce moment).

Voici l'interface habituelle de demande de fusion dans la production GitLab. Évidemment, nous pouvons réduire les fichiers, cliquer sur l'en-tête et le fichier commencera à se réduire.

Que pensez-vous, combien de temps faut-il pour réduire un fichier de 50 lignes, alors que la machine avec la huitième génération de Core i7 est tordue pour des performances maximales? Combien de temps dure le déploiement?

Le temps nécessaire à l'effondrement du fichier varie de 7 à 15 secondes. Le déploiement se produit instantanément. Avant la refactorisation, les deux fonctionnaient aussi rapidement.

C'est pourquoi il est très important d'avoir des métriques.

Je vais vous dire ce qui se passe ici. Voici Vue, son système de réactivité garde une trace de la valeur: s'il change, toutes les dépendances qui dépendent de cette valeur sont appelées. Chaque ligne est un composant Vue composé de plusieurs choses, car vous pouvez mettre des commentaires sur une ligne, les commentaires peuvent être chargés dynamiquement depuis le serveur, etc. Tout cela est souscrit au magasin Vue, qui est également un composant Vue.

Lorsque vous fermez la demande de fusion, tous, disons, 20 000 abonnements de magasin doivent être mis à jour lorsque le magasin est mis à jour. Si la ligne est supprimée, elle doit être supprimée des dépendances. Et puis des calculs simples: vous devez regarder un tableau de 20 000 éléments pour trouver ceux qui doivent être supprimés. Disons qu'il y a 500 lignes de ce type, et chaque ligne est constituée de plusieurs composants. Le résultat est une opération mathématique O (N), c'est-à-dire O (20 000) * 500. JavaScript fonctionne depuis tout ce temps.

Le déploiement se produit instantanément, car l'ajout d'une dépendance n'est qu'une poussée vers le tableau, c'est-à-dire opération mathématique O (1).

Parfois, l'amélioration de la qualité du code dégrade les performances et d'autres mesures. Il est très important de les mesurer.

En résumé: isolez le mauvais code et suivez les métriques.

legacy — . , – TechLead Conf — , . – , legacy Python, PHP.

, ++, , FrontendConf. .

Méthodes de traitement du code hérité en utilisant GitLab comme exemple