Bonjour, Habr! Lors du Luxoft TechFest qui s'est tenu le 28 janvier, Mikhail Zankovich, chef d'équipe senior chez Luxoft , a évoqué les applications avec une hérédité sévère. Aujourd'hui, il partage des réflexions supplémentaires impliquées dans le contenu de ce rapport, qui a suscité une discussion assez animée lors de la rencontre.
Quelles émotions et quelles associations la phrase «Nous avons un projet d'héritage» évoque-t-elle en vous? Le plus souvent - manque de structure, chaos, tonnes de code non documenté, horreur, anarchie architecturale, dégoût, une mer de béquilles, vous devez courir! Mes émotions: «Oh! Enfin, quelque chose d'intéressant. Faisons en sorte que ça marche! " Je soupçonne que c'est une réaction très inhabituelle.
Dans cet article, je vais essayer de révéler une idéologie différente du travail avec l'héritage. Désignons-le comme «restauration logicielle». Je n'ai pas l'intention de changer votre attitude envers Legacy, mais si vous parvenez au moins à semer le doute que Legacy peut être intéressant, je serai heureux.
Un héritage typique
Qu'est-ce que Legacy? D'après mon expérience, vous pouvez créer la liste de contrôle suivante pour la conformité des produits hérités:
- .
.. , , .
- .
, black-box. . . - .
, . - .
. / ..
Tout cela conduit au fait qu'il devient de plus en plus difficile de maintenir un tel projet à chaque version, tout comme l'élaboration de nouvelles fonctionnalités / nouvelles exigences. Tout changement se transforme en rétro-ingénierie avec des tests de régression obligatoires, etc. En conséquence, le projet devient coûteux à entretenir et est «gelé» dans sa forme actuelle avec la minimisation de tout changement.
Mais pourquoi les anciens produits apparaissent-ils?
Une équipe crée rarement consciemment et délibérément un produit de mauvaise qualité. Le plus souvent, c'est le résultat d'opportunités limitées par la situation actuelle du projet.
Il n'y a pas d'exigences claires - il n'y a aucune possibilité de conception équilibrée des fonctionnalités de l'application.
Des exigences en constante évolution, une formulation peu claire, des délais de mise en œuvre serrés, une dette technique en constante augmentation sont des signes évidents de processus de développement agiles dans une équipe qui n'a pas été en mesure de s'adapter pleinement à ces approches «agiles». Et à partir de "flexibles" seulement "les demandes changeantes rapidement de l'entreprise" fonctionnent.
Cela conduit souvent à une rotation accrue au sein de l'équipe, qui à son tour n'a pas d'effet positif sur la qualité. Imaginez qu'un nouveau spécialiste rejoigne l'équipe, pendant deux ou trois mois, il ne plonge que dans le processus, puis pendant un mois et demi ou deux, il met en œuvre une sorte de fonctionnalité et se prépare à quitter le projet. Il n'est pas intéressé par un produit de qualité, une documentation complète de sa part, un transfert de connaissances à des collègues, etc. L'expertise est floue.
À un moment donné, une décision fatale est prise: il est plus facile de remplacer / éteindre que d'accompagner. Et le projet entre dans la phase de «faible entretien», lorsqu'il est pris en charge sur une base résiduelle, en essayant de minimiser les changements, de créer des «béquilles» supplémentaires qui implémentent les nouvelles demandes rapidement mais mal. Pourquoi une haute qualité? Le produit changera. Dans ce mode, le produit peut survivre pendant de nombreuses années, devenir envahi par les «béquilles» et devenir plus monstrueux.
En résumant tout ce qui précède, les principales raisons suivantes de l'émergence de produits hérités peuvent être identifiées:
- des délais serrés pour la mise en œuvre de la fonctionnalité;
- manque d'exigences claires / exigences en constante évolution;
- rotation accrue au sein de l'équipe;
- mauvaise planification du cycle de vie.
Nous ajoutons ici le niveau de développement professionnel des spécialistes en ce moment. Ouvrez votre projet il y a cinq ou dix ans. Je suis sûr que vous pouvez facilement trouver des éléments que vous implémenteriez différemment maintenant.
Donc, nous prenons comme axiome: "le code n'est pas créé intrinsèquement mauvais". Cela signifie que tout produit avait une sorte d'idée. Et si le code entrait en production, cela fonctionnait et répondait aux besoins de l'entreprise à ce moment-là.
Approche d'escorte
Les tâches des clients sont assez simples: maintenir l'héritage en état de fonctionnement sans perturber les processus métiers actuels (dont certains sont généralement inconnus de personne), tout en développant la fonctionnalité en fonction des nouvelles exigences en fonction du budget, ce qui est très probablement limitée.
L'approche typique d'une équipe qui se lance dans un projet est de continuer à aggraver lentement mais sûrement les choses. Ne touchez pas trop, ne changez que ce qui vous est demandé et uniquement sur demande. Si le module fonctionne, mais nécessite une modification de la logique - laissez-le et ne le touchez pas - il est préférable d'en créer un autre, mais avec la logique nécessaire. Le chaos grandit, l'application se complique.
L'approche du restaurateur
L'approche d'un restaurateur de logiciel est de déterminer quel type de mécanisme se trouve devant lui. Quelle était l'idée principale de ses créateurs. Essayez de couper tout ce qui est inutile et gardez le meilleur. Si vous modifiez la structure existante, il est extrêmement prudent et attentif aux détails. Pas un seul détail affectant le système ne doit être caché à la vue du restaurateur. Les changements introduits sont d'abord élaborés selon la logique de maintenance, puis une analyse est effectuée pour déterminer la possibilité de mettre en œuvre une solution à part entière.
C'est un travail difficile et chronophage. Tous les développeurs ne sont pas disposés, et surtout, vraiment capables de faire de la restauration. Les exigences pour le niveau du restaurateur sont d'un ordre de grandeur plus élevé que pour un développeur ordinaire. Sans expérience de projets réels, sans comprendre comment les systèmes peuvent se développer, sans collision non seulement avec les meilleures approches en pratique, mais aussi avec des implémentations manifestement infructueuses, il ne sert à rien de restaurer.
Au lieu de la première envie typique «Oui, ce sont des béquilles! Tout doit être réécrit ici! " - un vrai restaurateur posera la question «Pourquoi cela a-t-il été fait de cette façon? Comment était-il prévu de l'utiliser exactement? " Et seulement après s'être assuré qu'il n'y avait pas de prérequis évident pour la création d'un tel code, le restaurateur peut s'exclamer: «Oui, ce sont des béquilles! Tout doit être réécrit ici! », Et avec un sentiment d'accomplissement, il peut vraiment interrompre une croissance inutile sur le cadre ossifié du logiciel, rendant l'objet de restauration meilleur et de meilleure qualité.
Mais cela arrive rarement, même si cela donne un plaisir indescriptible au restaurateur. Le plus souvent, vous devez démêler l'enchevêtrement des dépendances entre les différents modules. Il n'est pas rare que les fils s'étendent bien au-delà de la zone de responsabilité du composant à démonter (et parfois du système). Et toutes ces subtilités des relations entre les modules doivent être prises en compte lors de la restauration.
Ainsi, le restaurateur de logiciels travaille à l'intersection du développement, de l'architecture, de l'analyse commerciale, des tests et de la médecine. Et il est difficile de dire quelles compétences des domaines désignés sont la priorité absolue. Il doit y avoir un certain équilibre entre eux, assaisonné d'un désir honnête de s'engager dans la restauration. Qu'est-ce que la médecine a à voir avec cela? Ainsi, le principe principal du restaurateur est «primum non nocere» - tout d'abord, ne pas nuire.
En fait, cette approche sera examinée plus avant sur des exemples spécifiques, en démontant et en restaurant progressivement l'héritage typique hérité des anciens propriétaires techniques de systèmes. Et avec des exemples spécifiques, voyons pourquoi toutes les compétences ci-dessus sont importantes.
Restauration de l'entrepôt de données
Que stocke le système?
Atterrissant sur un nouveau projet, le restaurateur fera attention aux objets traités par le système. Pour vous immerger pleinement dans les flux métiers et le code source, notamment en l'absence de documentation normale, cela prendra au moins plusieurs mois.
L'une des premières tâches d'un restaurateur est d'évaluer l'efficacité de la voûte. Pouvez-vous améliorer quelque chose sans vous fier à une compréhension des processus métier? Un problème typique de tout entrepôt de données est principalement lié au volume de ces données. Plus le volume est important, plus le coût de possession du système est élevé.
Le deuxième point douloureux est la croissance de ce volume même, qui affecte négativement les performances du système en premier lieu. Très probablement, il existe déjà des pratiques pour conserver les informations dans le système, mais dans quelle mesure sont-elles efficaces?
Toutes les pratiques envisagées ici sont plus applicables aux SGBDR classiques, mais l'approche n'est pas très différente pour les solutions no-sql.
L'une des principales tactiques du restaurateur dans ce sens est la création de surveillance des objets de stockage d'informations. Dans le cas du SGBD classique, surveillance de table.
Un cadre est nécessaire pour permettre aux métadonnées du système de collecter périodiquement des données sur deux paramètres triviaux - la quantité de données et le nombre d'éléments dans chaque tableau. La fréquence devra être sélectionnée manuellement (plus de détails ci-dessous), en fonction des caractéristiques du système. Une période de démarrage typique de 24 heures est suffisante pour une analyse de base.
Analyse des données
Que faire des données? Ce qu'il faut chercher? Le premier moment est d'identifier les objets les plus «lourds». Dans la pratique, la règle standard 20/80 fonctionne - pas plus de 20% des objets n'utiliseront plus de 80% de l'espace. Cela vous permet de réduire considérablement la zone d'analyse lors de la première étape.
Plus ces statistiques sont accumulées longtemps et avec plus de détails, plus le comportement du système est clairement reflété. L'expérience a montré que la période recommandée est d'au moins deux semaines. L'idée principale consiste à «accrocher» les jours / périodes non ouvrés dans lesquels les mécanismes de nettoyage et d'archivage des informations sont le plus souvent mis en œuvre.
Alors le framework est écrit, et le restaurateur attend les résultats pendant deux semaines? Bien sûr que non. Il ne combat pas l'idéologie du restaurateur. Avec le premier bloc de données en main, vous pouvez effectuer une analyse de base. À savoir - pour voir le rapport de l'espace occupé au nombre d'objets stockés (lignes). Plus cette valeur est élevée, plus il est probable que les champs BLOB soient stockés ici. Et seuls ces tableaux et ces champs font l'objet de recherches et d'analyses pour le restaurateur.
Questions clés: à quelle fréquence les processus métier accèdent-ils réellement à ces objets? Le propriétaire du système, l'équipe existante, peut faire la lumière sur ces points. Et du coup (et en pratique très souvent) il s'avère que de tels champs stockent des informations qui ne sont pas importantes pour l'entreprise: vidages d'objets / messages pour analyse par l'équipe de développement, commentaires des utilisateurs affichés uniquement lors de la création d'une commande, etc.
Étape suivante: si les données ne sont pas utilisées fréquemment ou n'ont pas de valeur commerciale claire, pourquoi ne pas les déplacer vers l'archive? Dans le même temps, une approche cardinale consistant à diviser une table monolithique en plusieurs parties, à déplacer les blobs vers un support moins cher / plus lent, mais en même temps en préservant l'interface d'origine de la table (le point principal est qu'il n'y a pas d'informations fiables sur tous processus d'accès à ces informations, ce qui signifie que les changements ne devraient pas leur nuire) - peut être un problème technique assez intéressant et complexe.
Une tâche moins intéressante mais tout aussi utile consiste à utiliser le système de stockage de données intégré pour archiver les valeurs de certains champs. Par exemple, Sybase ASE a la fonction ASE_Compression, Mongo DB vous permet de définir les options de compression pour les collections, etc. Presque tous les systèmes de stockage de données ont l'option de compression de données supplémentaire «sous le capot». La fonctionnalité fonctionnera de manière transparente pour les systèmes externes et ne nécessitera pas de changements drastiques. Dans la pratique (en particulier sur les systèmes hérités), ces options de compression de données ne sont pas utilisées par défaut.
Bien entendu, lors de l'application de la compression, le restaurateur doit d'abord évaluer l'impact de l'approche sur les performances, et pour cela, des indicateurs de performance clés du système doivent être élaborés ou, dans les cas extrêmes, des éléments de test de régression doivent être présents.
En général, il y a quelque chose à faire pendant quelques semaines pendant que des statistiques complètes sur les objets sont collectées.
Grandes statistiques: ce qu'il faut rechercher
Après avoir reçu des statistiques sur une longue période de temps, le restaurateur essaie de comprendre ce qui se passe avec la dynamique de l'espace utilisé. Toutes les valeurs d'une table / d'un objet sont normalisées par rapport à l'original. Cela permettra d'estimer précisément l'augmentation relative des données et d'identifier les objets qui changent le plus intensément.
Le profil généré correspondra probablement à l'un des types suivants:
Profil 1 - valeur constante. Très probablement, ce sont des répertoires statiques et il n'est pas si intéressant de travailler avec eux. L'approche d'archivage décrite ci-dessus peut être appliquée en fonction de l'intensité d'utilisation du répertoire.
Petites fluctuations de volume - profil 2- ils peuvent parler à la fois d'un ouvrage de référence et d'une table opérationnelle, dans lesquels la lecture / écriture des données est intensive. Ce sont les objets les plus difficiles du point de vue du restaurateur, car il est nécessaire d'analyser leur comportement le plus en détail possible. C'est pour ces objets qu'il est logique d'augmenter la fréquence de collecte d'informations: pas une fois par jour, mais une fois par heure, une fois par minute. L'objectif principal est de retracer le changement de profil plus en détail et de comprendre les dépendances de comportement.
Les profils 3 et 4 sont plus intéressants. Profil 3(«Saw») indique clairement que ce tableau est périodiquement effacé. Mais la tendance croissante - à chaque fois après le nettoyage, le volume final est légèrement supérieur à ce qu'il était auparavant - parle de l'inefficacité des mécanismes de nettoyage existants. Ceux. sur une certaine période de temps, plus de données apparaissent dans le système que celles supprimées à la fin de la période. Cela peut être un processus commercial tout à fait normal, une augmentation classique de la charge sur le système.
Mais pour le restaurateur, c'est avant tout un signal: y a-t-il des conditions pour supprimer des informations? Sur la base de la pratique, il est fort probable que certaines entités, en raison des conditions complexes de conservation des données dans le système, restent à jamais dans le stockage. Le but du restaurateur est d'identifier ces entités et de les inclure également dans les activités périodiques.
Si le profil 3 dégénère en croissance constante, c'est le premier prétendant à un goulot d'étranglement dans le système. Premièrement, il n'y a pas de pointeurs explicites vers le processus d'archivage, et deuxièmement, une dégradation des performances est attendue avec la croissance des données.
Profil 4- un exemple typique de table d'archive avec remplissage périodique des données. Veuillez noter que la croissance de la table ne se produit que certains jours. Il est fort possible que des corrélations avec les tables du troisième profil soient perceptibles. Pour les tables d'archives, il est également important de comprendre le principe de leur utilisation - y a-t-il un appel des utilisateurs? Ou est-ce une histoire à analyser? Ou s'agit-il de données pour les systèmes de rapports? En fonction des réponses à ces questions, il est fort possible qu'une décision soit prise de séparer les tables d'archives en un circuit séparé, une base séparée, une section séparée. Ainsi, libérant l'espace opérationnel.
Comment ça marche en pratique?
Dans l'un des projets, un exercice similaire a été réalisé au cours du premier mois et demi après avoir rejoint le projet. Ce sont les objets du profil n ° 3 qui étaient la cible, et ils ont été retrouvés. Application des pratiques décrites (amélioration des conditions de nettoyage), suppression des données non utilisées dans le système, etc. permis de réduire le volume de l'espace occupé de plus de 25%, ainsi que d'arrêter la croissance intensive du stockage.
En conséquence, nous avons pu apporter les premières modifications techniques au projet et soumettre des plans pour améliorer la fonctionnalité. Le client était satisfait du résultat de l'équipe et elle est passée de 3 à 9 développeurs. Tout au long de l'année, nous avons poursuivi nos investigations, les points d'amélioration de la fonctionnalité ont été utilisés pour soutenir le système et ses caractéristiques.
Deux analystes nous ont été ajoutés, si bien que l'équipe a commencé à s'engager dans son propre développement - pas de support, mais la mise en œuvre de nouvelles fonctionnalités commerciales. Nous développons actuellement un nouveau système.
A quoi ça sert?
Si vous avez lu jusqu'ici, vous cherchez probablement une réponse à la question: "Pourquoi tout cela?" Tout d'abord, la restauration est un processus séparé, pas comme le développement, pas comme le support, mais en les combinant.
Il s'agit d'un lecteur distinct pour un spécialiste technique: se plonger dans la logique de la personne qui a créé ce produit, comprendre sa signification, nettoyer le produit des choses inutiles et le rendre encore meilleur qu'il ne l'était. L'application ressemble à une quête, avec de nombreux mystères et des rebondissements inconnus.
Non, vous ne créez pas à partir de zéro, vous restaurez un produit existant, mais peut-être détruit par le temps. Entre autres choses, le restaurateur a une occasion unique de pomper dans l'une des six directions (voir l'image ci-dessus), tout en ayant un vrai produit à portée de main comme base de test. Un sentiment de maîtrise de soi est également pompé - non pas pour tomber dans le perfectionnisme technique, mais pour réfléchir et faire uniquement les changements nécessaires au système en termes d'amélioration des processus.
Tout cela rend le travail avec des systèmes existants passionnant et inhabituel. Mais le choix final de restaurer ou de maintenir vous appartient.
Le rapport de Mikhail Zankovich au Luxoft TechFest peut être consulté ici .
L'auteur de l'article est Mikhail ZankovichMikhailZankovich