Analyse de code à grande échelle. Explorer les façons dont les ingénieurs seniors… | de Diego Pacheco | décembre 2022

Explorer les façons dont les ingénieurs seniors créent des inventaires et analysent le code au lieu de simplement les supprimer sans analyse

Avez-vous déjà réfléchi à la façon d’évaluer un logiciel en dehors du contexte de construction vs achat ? Cela ressemble à une question folle, non? Eh bien, la réalité est que vous devez faire plus que tout refactoriser pour pouvoir refactoriser à grande échelle. Les réécritures, les refactorisations et la réarchitecture doivent être opportunistes et apporter une réelle valeur ajoutée à l’entreprise.

Donc, s’il est assez difficile de tout refactoriser, comment pouvez-vous aborder les logiciels à grande échelle ?

Il est important de rationaliser la situation, car la rationalisation conduit à une hiérarchisation appropriée. Lorsqu’il est associé à une bonne exécution, il peut être un outil puissant pour apporter des changements et améliorer la qualité. Premièrement, la question peut sembler un peu écrasante et difficile, mais lorsque vous plongez profondément, vous réalisez ce qui a du sens et ce qui ne l’est pas. Après cela, certaines formes émergent. Alors, avant d’aller trop loin dans ce sujet, commençons par une question simple : pourquoi évaluer un logiciel ?

Outre le contexte de la construction par rapport à l’achat, il existe de nombreuses raisons d’évaluer un logiciel, telles que :

• Compréhension. Comment ça marche ? Qu’est-ce qui ne marche pas ? Comment cela pourrait-il aller mieux?
• Priorisation. Doit-on d’abord améliorer le Service A ou le Service B ?
• Décider. Devrions-nous désactiver le service A ou le réparer ? Qu’est-ce qui va bien ? Ce qui n’est pas?
• Stratégie. Doit-on le faire ? Doit-on déléguer à une entreprise ? Doit-on commencer une nouvelle base de code ? Doit-on fusionner/diviser les bases de code ?

L’évaluation est importante car elle apporte de la clarté au tableau et vous donne des données sur ce qui est utile sur plusieurs fronts, tels que les suivants :

• Évangélisez votre équipe pour changer les choses
• Évangéliser le reste de l’entreprise pour un plus grand changement, souvent sous forme de projet ou d’initiative
• Évitez les efforts sur les logiciels qui nécessitent une maintenance (cela s’applique que le logiciel soit mis hors service, remplacé ou remplacé par un autre outil). Par exemple, passer trop de temps sur les relations publiques pour de nouvelles « fonctionnalités »
• Éviter davantage de problèmes en accélérant certaines initiatives clés, comme le démantèlement d’un monolithe

À mon humble avis, vous devez répondre à la question suivante : Pouvons-nous vivre avec ce logiciel ? Cela ne signifie pas que le logiciel est exempt de dettes et de bogues ou parfait, mais cela signifie qu’il est gérable et raisonnable. Maintenant, qu’est-ce qui pourrait raisonnablement changer d’une entreprise à l’autre ?

Les gens sont assez bons pour s’habituer aux problèmes et les contourner. C’est une bonne chose, ne vous méprenez pas, mais il y a un moment où cette manœuvre coûte trop cher, et peu de gens peuvent le faire. C’est un bon signe que nous pourrions avoir besoin d’aide avec ce logiciel particulier.

À grande échelle, il y a toujours un problème. Il y a toujours des logiciels qui doivent être réécrits et il y a toujours une dette technique. Les entreprises qui réussissent ont beaucoup de dettes techniques – et c’est très bien. Cela ne signifie pas que nous devons cesser de nous battre. Au lieu de cela, nous devons continuer à lutter contre la complexité et à la gérer. Une bonne façon de commencer est d’évaluer ce que vous avez entre les mains. L’évaluation est importante car c’est le principal résultat pour lutter contre la complexité aux côtés de la densité des talents et de la bonne culture d’ingénierie.

Pour évaluer un logiciel, nous devons examiner le code ; il n’y a aucun moyen d’évaluer simplement en parlant aux gens. Les entretiens sont intéressants et utiles mais limités au statu quo et à la culture actuels. Même si vous lisez le code, que devriez-vous rechercher ? Prenons trois exemples.

Exemple 1 — migration de bibliothèque

Supposons que vous envisagez de déployer une bibliothèque partagée commune interne utilisée par toute l’entreprise, et cette bibliothèque est essentielle. Vous avez donc apporté quelques modifications aux API publiques et rompu la rétrocompatibilité. Maintenant, avec ce scénario à l’esprit, vous pouvez rechercher les éléments suivants dans la base de code de votre consommateur :

• Combien de consommateurs brisons-nous ?
• Quels sont les cas d’utilisation ? Comment utilisent-ils votre solution ?
• Voyons-nous des anti-modèles ou des abus de code ?
• Dans le cas de changements cassants, pouvons-nous fournir une recette (étapes) pour effectuer la migration ou faire évoluer le code pour la nouvelle version ?

Les cadres établis ont souvent des journaux des modifications et des guides de migration. Pour une raison étrange, les bibliothèques partagées internes n’ont souvent pas cela. La lecture du code de vos consommateurs peut vous fournir les données nécessaires pour planifier votre migration dans le sens de l’effort et fournir les bonnes attentes et appels dès le départ.

Exemple 2 — fixation d’un monolithe classique et/ou d’un monolithe distribué

Maintenant, disons que nous devons créer une nouvelle fonctionnalité. Cela nécessitera la création de nouvelles tables et la modification de votre base de code actuelle. C’est l’occasion idéale de le faire différemment – peut-être ajouter un nouveau service, utiliser une nouvelle base de données ou même refactoriser celle existante. Maintenant, la question que vous devez vous poser est : est-ce la bonne chose ? Améliorons-nous ou aggravons-nous les choses ? Encore une fois, pour répondre à cette question, nous devons faire une évaluation du code en recherchant ce qui suit :

• Quel est le degré d’isolement du code ? Les nouvelles tables sont-elles isolées des autres ?
• Le code a-t-il une interface de service devant la base de données ? La base de données est-elle partagée ?
• Quelles sont les dépendances de service en amont et en aval ?
• Avons-nous un contrat clair, simple et explicite pour le service ?
• Qu’en est-il des bibliothèques partagées internes ? Y a-t-il des abus ou des bibliothèques lourdes utilisées ?
• À quoi ressemble la couverture de test ? Existe-t-il des tests couvrant les marchés publics ?

De nouveaux services peuvent être de bonnes choses, mais ne les prenez pas pour acquis. Vous pourriez aggraver et grossir un monolithe distribué, alors évaluez-le avant de vous déplacer.

Exemple 3 — réorganisation d’entreprise

Disons que votre entreprise change de direction d’un domaine à un autre. Il est courant pour les entreprises de faire pivoter le modèle commercial, d’acquérir, de vendre et d’avoir plusieurs entreprises qui pourraient augmenter et disparaître tout le temps. Tout cela implique que vous pourriez avoir besoin d’un changement de propriétaire, mais qui sera propriétaire, et de quoi ? Vous pourriez commencer à gérer un tas de logiciels que vous ne gériez pas auparavant.

Faire une évaluation du code est une bonne idée pour mieux hiérarchiser les actions futures de votre équipe ou même décider quelles équipes devraient posséder quel logiciel. Dans ce cas, nous pourrions rechercher les éléments suivants :

• Quelle est la fréquence des changements dans l’entreprise ?
• À quoi ressemble la couverture de test ? Existe-t-il des tests couvrant les marchés publics ?
• Avons-nous de l’isolement sur les contrats et les bases de données des services ?
• Combien de dette technique avons-nous ? Quels sont les pires contrevenants ?

Les évaluations sont importantes car, face aux opportunités, vous saurez en tirer le meilleur parti. Sinon, vous pourriez faire plus de la même chose et perdre de précieuses opportunités d’améliorer la situation.

Odeurs, risques et caractéristiques

Les odeurs de code et de design peuvent vous aider. Ils ne signifient pas 100% de problèmes et ont différents niveaux de criticité. Par exemple, un DSL interne mal écrit sera préférable à un manque d’isolation de la base de données, c’est-à-dire partager une base de données avec trois services de domaines commerciaux différents.

Les risques doivent être examinés en examinant leurs tendances. Cela signifie que les choses vont s’améliorer ou empirer avec le temps. Les traits sont des comportements courants que vous pouvez attendre des logiciels et des équipes, et ils mettent à jour l’état en temps réel. Par exemple,

• Les monolithes classiques ont tendance à être pleins de dettes techniques. Par conséquent, ils forcent les microservices à se produire.
• L’explosion de mauvais microservices tend à partager des bases de données avec la création de monolithes distribués.
• Les monolithes distribués ont tendance à empirer avec le temps car ils sont difficiles à tester et à faire évoluer. Cela peut vous obliger à penser à nouveau en monolithes et à tourner en rond.

Les inventaires sont importants et excellents pour résumer les résultats. Peu importe que vous effectuiez une migration de bibliothèque interne, répariez des monolithes ou réorganisiez une équipe ou un produit. L’inventaire peut être fait avec une simple feuille ou une page wiki. Construire des inventaires prend beaucoup de temps, mais c’est payant.

Comment savez-vous que vous menez les bons combats ?

Malheureusement, à grande échelle, tous les problèmes ne peuvent pas être résolus en même temps. La priorisation est nécessaire pour être pratique et obtenir les résultats souhaités. Cela ne signifie pas abandonner ou ignorer les problèmes, mais avoir des gains rapides et créer une dynamique pour apporter davantage d’améliorations.

Effectuez toujours des évaluations. Savoir ce qui se passe dans le code est essentiel pour faire de bons appels et comprendre la complexité. N’importe qui peut effectuer une analyse de code ; presque toutes les entreprises ont aujourd’hui un GitHub, un GitLab ou une interface Web consultable qui est publique ou interne. Télécharger le code source et lire votre IDEA est une bonne idée.

Lire du code est beaucoup plus difficile que d’écrire du code. Notre industrie croit que les ingénieurs juniors écrivent du code et que les ingénieurs seniors en suppriment. Mais à mon humble avis, les ingénieurs seniors créent des inventaires et analysent le code au lieu de simplement le supprimer sans analyse.

Salutations,

Diego Pachéco