🚴🏽 🕤 👕 Comment lire et corriger 100 000 lignes de code par semaine 👩‍❤️‍👨 🖐🏽 💢

Au début, il est toujours difficile de comprendre le grand et le vieux projet. L'évaluation de l'architecture est l'une des activités de l'architecte. Habituellement, vous devez travailler avec de grands projets anciens et les résultats doivent être fournis en une semaine.

Comment évaluer un projet avec une taille de 100k ou plus de lignes de code par semaine tout en fournissant des résultats vraiment utiles pour le client.

La plupart des architectes et ces responsables ont rencontré des évaluations de projets similaires. Cela peut ressembler à un processus semi-formel ou à un service distinct comme cela se fait dans notre entreprise, de toute façon la plupart d'entre vous y ont fait face.

L'anglais original pour vos amis non russophones est ici: Évaluation de l'architecture dans une semaine .

L'approche dans notre entreprise

Je vais vous dire comment cela fonctionne dans notre entreprise et comment j'agis dans de telles situations, mais vous pouvez facilement changer cette approche en fonction des besoins de votre projet et de votre entreprise.

Il existe deux types d'évaluation de l'architecture.

Interne - nous le faisons généralement pour des projets au sein de l'entreprise. Tout projet peut demander une évaluation de l'architecture pour plusieurs raisons:

L'équipe pense que leur projet est parfait et c'est suspect. Nous avons eu de tels cas et souvent dans de tels projets, tout est loin d'être parfait.
L'équipe souhaite tester son projet et ses décisions.
L'équipe sait que tout va mal. Ils peuvent même énumérer les principaux problèmes et causes, mais ils veulent une liste complète des problèmes et des recommandations pour améliorer le projet.

L' évaluation externe est un processus plus formel que l'évaluation interne. Un client ne vient toujours que dans un cas où tout est mauvais - très mauvais. Habituellement, le client comprend qu'il existe des problèmes globaux, mais ne peut pas déterminer correctement les causes et les décomposer en composants.

L'évaluation de l'architecture d'un client externe est un cas plus complexe. Le processus devrait être plus formel. Les projets sont toujours grands et anciens. Ils ont beaucoup de problèmes, de bugs et de code tordu. Un rapport sur le travail effectué devrait être prêt dans quelques semaines maximum, où devraient figurer les principaux problèmes et recommandations d'amélioration. Par conséquent, si nous traitons de l'évaluation externe du projet, alors en interne, ce sera un non-sens. Prenons le cas le plus difficile.

Évaluation de l'architecture d'un projet d'entreprise

Un projet d'évaluation typique est un grand projet d'entreprise ancien avec beaucoup de problèmes. Un client vient nous voir et demande de fixer son projet. C'est comme avec un iceberg, le client ne voit que la pointe de ses problèmes et ne sait pas ce qu'il y a sous l'eau (au dos du code).

Problèmes dont le client peut se plaindre et peut les connaître:

Les problèmes de performance
Problèmes d'utilisation
Déploiement long
Manque d'unité et autres tests

Problèmes que le client n'est probablement pas au courant, mais ils peuvent être présents dans le projet:

Problèmes de sécurité
Les problèmes de conception
Architecture incorrecte
Erreurs algorithmiques
Technologie inappropriée
Dette technique
Processus de développement non valide

Processus formel d'évaluation de l'architecture

Il s'agit d'un processus formel auquel nous adhérons dans l'entreprise, mais vous pouvez l'ajuster vous-même en fonction de votre entreprise et de votre projet.

Demande du client

Le client demande d'évaluer l'architecture du projet en cours. La personne responsable de notre part recueille des informations de base sur le projet et sélectionne les experts nécessaires. Selon le projet, il peut s'agir de différents experts.

L'architecte de solutions est la principale personne responsable de l'évaluation et de la coordination (et souvent la seule).
Empilez des experts spécifiques - .Net, Java, Python et d'autres experts techniques en fonction du projet et des technologies d'
experts Cloud - il peut s'agir d'architectes cloud Azure, GCP ou AWS.
Infrastructure - DevOps, administrateur système, etc.
Les autres experts sont le big data, l'apprentissage automatique, l'ingénieur de performance, l'expert en sécurité, le responsable QA.

Collecte d'informations sur le projet

Vous devez collecter autant d'informations que possible sur le projet. Vous pouvez utiliser différentes techniques selon la situation:

Questionnaires et autres moyens de communication par courrier. La manière la plus inefficace.
Réunions en ligne.
Outils spéciaux pour l'échange d'informations tels que: Google doc, Confluence, référentiels, etc.
Réunions «en direct» en place. Le moyen le plus efficace et le plus cher.

Que doit-on recevoir du client?

Informations de base. De quoi parle le projet? Son but et sa valeur. Les principaux objectifs et plans pour l'avenir. Objectifs et stratégies d'entreprise. Les principaux problèmes et le résultat souhaité.

Informations sur le projet . Pile technologique, frameworks, langages de programmation. Déploiement sur site ou cloud. Si le projet est dans le cloud, quels services sont utilisés. Quels modèles architecturaux et de conception ont été utilisés.

Pas d'exigences fonctionnelles . Toutes les exigences liées aux performances, à la disponibilité, à l'utilisabilité du système. Exigences de sécurité, etc.

Juskeys de base et flux de données.

Accès au code source . La partie la plus importante! Vous devriez certainement avoir accès aux référentiels et à la documentation sur la façon d'assembler un projet.

Accès à l'infrastructure . Ce serait bien d'avoir accès à la scène ou à l'infrastructure de production afin de travailler avec un système en direct. C'est un grand succès si le client dispose d'outils pour surveiller l'infrastructure et la productivité. Nous parlerons de ces outils dans la section suivante.

Documentation . Si le client a de la documentation, c'est un bon début. C'est peut-être dépassé, mais c'est quand même un bon début. Ne croyez jamais la documentation - vérifiez-la avec le client, sur une infrastructure réelle et dans le code source.

Processus d'évaluation de l'architecture

Comment alors traiter une si grande quantité d'informations en si peu de temps? Tout d'abord, parallélisez le travail.

Les DevOps devraient se pencher sur l'infrastructure. Je les mets dans le code. L'ingénieur de performance voit les mesures de performance. Un spécialiste des bases de données devrait approfondir les structures de données.

Mais c'est un cas idéal lorsque vous avez beaucoup de ressources. En règle générale, un projet est évalué par une à trois personnes. Vous pouvez même effectuer une évaluation vous-même, ce qui arrive souvent si vous avez les connaissances et l'expérience appropriées dans tous les domaines du projet. Dans ce cas, vous devez automatiser autant que possible tous les processus.

Malheureusement, vous devrez lire la documentation manuellement. Avec l'expérience appropriée, vous pouvez rapidement comprendre la qualité de la documentation. Ce qui est vrai là-bas et ce qui ne coïncide clairement pas avec la réalité. Parfois, vous pouvez trouver une telle architecture dans la documentation qui ne fonctionnera jamais dans la vraie vie. C'est un déclencheur auquel vous devez réfléchir, mais comment cela se fait-il en réalité dans le projet.

Outils utiles pour automatiser l'évaluation de projet

L'évaluation d'un code est un exercice simple. Vous pouvez utiliser des analyseurs de code statiques pour afficher les problèmes de conception, de performances et de sécurité. En voici quelques-unes: La

structure 101 est un excellent outil pour un architecte. Il vous montrera la vue d'ensemble, la relation entre les modules et les domaines potentiels de refactoring. Comme tous les bons outils, cela coûte beaucoup d'argent, en même temps vous pouvez utiliser la version d'essai de 30 jours.

SonarQube est un bon vieil outil. Outil d'analyse de code statique. Vous permet d'identifier le mauvais code, les bogues, les problèmes de sécurité pour plus de 20 langages de programmation.

Tous les fournisseurs de cloud disposent d'outils de surveillance de l'infrastructure. Cela vous permettra d'évaluer correctement l'efficacité de l'infrastructure en termes de coût et de performance. Pour AWS, il s'agit d'un conseiller de confiance . Pour Azure, c'est juste un conseiller Azure .

Une surveillance et une journalisation supplémentaires des performances peuvent vous aider à identifier les problèmes de performances à tous les niveaux. À partir d'une base de données avec des requêtes inefficaces, un backend et se terminant par un frontend. Même si le client n'a pas installé ces outils auparavant, vous pouvez les intégrer rapidement dans votre système existant pour identifier les problèmes de performances.

Comme toujours, de bons outils en valent la peine. Je peux recommander quelques outils payants. Bien sûr, vous pouvez utiliser l'open source mais vous aurez besoin de plus de temps pour cela. Et cela doit être fait à l'avance, et non dans le processus d'évaluation de l'architecture.

New Relic - outil d'évaluation des performances des applications
Datadog - service de surveillance sœur basé sur le cloud

Il existe de nombreux outils pour les tests de sécurité. Cette fois, je vous recommanderai un outil d'analyse système gratuit.

OWASP ZAP est un outil d'analyse des applications Web pour la conformité aux normes de sécurité.

Mettre tous ensemble.

Nous préparons un rapport

Commencez votre rapport avec les données client. Décrivez les objectifs du projet, les limites et les exigences non fonctionnelles. Après cela, toutes les données entrantes doivent être mentionnées: code source, documentation, infrastructure.

La prochaine étape. Répertoriez tous les problèmes que vous avez détectés manuellement ou à l'aide d'outils automatisés. Placez de gros rapports générés automatiquement à la fin dans la section des applications. Voici des preuves brèves et succinctes des problèmes rencontrés.
Priorisez les problèmes trouvés sur l'échelle d'erreur, d'avertissement et d'information. Vous pouvez choisir votre propre échelle, mais cela est généralement accepté.

En tant que véritable architecte, vous devez fournir des recommandations sur la façon de résoudre les problèmes que vous avez trouvés. Décrivez les améliorations et la valeur pour l'entreprise que le client recevra. Comment montrer la valeur commerciale derefactoring d'architecture dont nous avons discuté précédemment.

Préparez une feuille de route avec de petites itérations. Chaque itération doit contenir du temps pour l'exécution, la description, la quantité de ressources nécessaires pour l'amélioration, la valeur technique et la valeur pour l'entreprise.

Nous terminons l'évaluation de l'architecture et fournissons au client un rapport

N'envoyez jamais un rapport par la poste. Il peut ou non être lu du tout ou lu et non compris sans explication appropriée. En bref, la communication en direct aide à éliminer les malentendus entre les personnes. Vous devez organiser une réunion avec le client et parler des problèmes détectés, en vous concentrant sur les plus importants. Il vaut la peine de prêter attention au client à des problèmes qu'il ne soupçonne même pas. Tels que les problèmes de sécurité et expliquer comment ils peuvent affecter une entreprise. Montrez votre feuille de route avec des améliorations et discutez des différentes options qui conviennent mieux au client. Cela peut être du temps, des ressources, du travail.

En résumé de votre rallye, envoyez votre rapport au client.

finalement

L'évaluation de l'architecture est un processus complexe. Pour mener une évaluation correctement, vous devez avoir suffisamment d'expérience et de connaissances.

C'est réel - fournir au client des résultats utiles pour lui et son entreprise en seulement une semaine. Même si vous le faites seul.

D'après mon expérience, de nombreuses améliorations ont été téléchargées au milieu et parfois n'ont jamais commencé. Ceux qui ont choisi un terrain d'entente pour eux-mêmes et n'ont apporté qu'une partie des améliorations les plus utiles aux entreprises avec un minimum de main-d'œuvre, ont considérablement amélioré la qualité de leur produit. Ceux qui n'ont rien fait après quelques années ont pu clôturer complètement le projet.

Votre objectif est de montrer au client l'amélioration maximale au prix le plus bas.

D'autres articles de la section architecture peuvent être lus à votre guise.

Je vous souhaite du code propre et de bonnes solutions architecturales.

Notre groupe Facebook est Architecture et développement logiciel .

Comment lire et corriger 100 000 lignes de code par semaine