Il est toujours difficile de naviguer dans un grand projet ancien au début. L'évaluation de l'architecture est l'une des activités de l'architecte. On doit généralement travailler sur de grands projets anciens et les résultats doivent être fournis en une semaine.
Comment évaluer un projet de 100 000 lignes de code ou plus en une semaine tout en fournissant des résultats réellement utiles pour le client.
La plupart des architectes et des chefs techniques ont été confrontés à ce genre d'évaluations de projets. Cela peut sembler être un processus semi-formel ou un service distinct comme cela se fait dans notre entreprise, quoi qu'il en soit, la plupart d'entre vous ont déjà eu affaire à cela.
L'original en anglais pour vos amis non russophones se trouve ici : .
Approche dans notre entreprise
Je vais vous expliquer comment cela fonctionne dans notre entreprise et comment j'agis dans de telles situations, mais vous pouvez facilement adapter cette approche en fonction des besoins de votre projet et de votre entreprise.
Il y a 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 des cas comme ça et souvent dans ces projets, tout n'est pas si parfait.
- L'équipe souhaite vérifier son projet et ses solutions.
- L'équipe sait que tout va mal. Elle peut même énumérer les principaux problèmes et raisons, mais souhaite obtenir une liste complète de problèmes et des recommandations pour améliorer le projet.
Externe – c'est un processus plus formel que l'évaluation interne. Le client arrive toujours dans un seul cas : quand tout va mal – très mal. Généralement, le client comprend qu'il y a des problèmes globaux, mais ne peut pas identifier les causes correctement et les décomposer.
L'évaluation de l'architecture pour un client externe est un cas plus compliqué. Le processus doit être plus formel. Les projets sont toujours grands et anciens. Ils contiennent de nombreux problèmes, bogues et du code mal écrit. Le rapport des travaux réalisés doit être prêt dans un délai maximum de quelques semaines, avec les principaux problèmes et des recommandations pour améliorer. Donc, si nous comprenons l'évaluation externe du projet, alors l'interne ne sera qu'une simple formalité. Prenons le cas le plus complexe.
Évaluation de l'architecture d'un projet d'entreprise
Un projet typique pour une évaluation est un grand projet ancien, d'entreprise, avec de nombreux problèmes. Le client vient vers nous et demande de réparer son projet. C'est comme un iceberg, le client ne voit que le sommet de ses problèmes et n'a aucune idée de ce qui se cache sous l'eau (dans les profondeurs du code).
Problèmes dont le client peut se plaindre et dont il peut être conscient :
- Problèmes de performance
- Problèmes d'utilisation de l'application (Usabilité)
- Déploiement prolongé
- Absence de tests unitaires et autres tests
Problèmes dont le client n'est probablement pas conscient, mais qui peuvent exister dans le projet :
- Problèmes de sécurité
- Problèmes de conception
- Architecture incorrecte
- Erreurs algorithmiques
- Technologies inappropriées
- Dette technique
- Processus de développement incorrect
Processus formel d'évaluation de l'architecture
C'est un processus formel que nous suivons dans l'entreprise, mais vous pouvez l'adapter en fonction de votre entreprise et de votre projet.
Demande du client
Le client demande une évaluation de l'architecture du projet actuel. La personne responsable de notre côté collecte les informations de base sur le projet et sélectionne les experts nécessaires. En fonction du projet, il peut s'agir d'experts différents.
Architecte de solutions – personne principale responsable de l'évaluation et de la coordination (et souvent la seule).
Experts spécifiques à la stack – .Net, Java, Python, et autres spécialistes techniques en fonction du projet et des technologies
Experts en cloud – il peut s'agir d'architectes cloud Azure, GCP ou AWS.
Infrastructure – DevOps, Administrateur système, etc.
Autres experts – tels que big data, machine learning, ingénieur performance, expert en sécurité, responsable QA.
Collecte d'informations sur le projet
Vous devez collecter autant d'informations que possible sur le projet. Vous pouvez utiliser diverses techniques en fonction de la situation :
- Questionnaires et autres moyens de communication par e-mail. Le moyen le moins efficace.
- Réunions en ligne.
- Outils spécialisés pour l'échange d'informations tels que : Google doc, Confluence, dépôts, etc.
- Réunions 'en direct' sur place. Le moyen le plus efficace et le plus coûteux.
Que faut-il obtenir du client ?
Informations de base. De quoi parle le projet. Son objectif et sa valeur. Objectifs principaux et plans futurs. Objectifs commerciaux et stratégies. Problèmes clés et résultats souhaités.
Informations sur le projet. Stack technologique, frameworks, langages de programmation. Déploiement sur site ou dans le cloud. Si le projet est dans le cloud, quels services sont utilisés ? Quels modèles architecturaux et de design ont été appliqués ?
Exigences non fonctionnelles. Toutes les exigences liées à la performance, la disponibilité, la facilité d'utilisation du système. Exigences de sécurité, etc.
Cas d'utilisation de base et flux de données.
Accès au code source. La partie la plus importante ! Vous devez absolument obtenir l'accès aux dépôts et à la documentation sur la manière de constituer le projet.
Accès à l'infrastructure. Il serait bon d'accéder à l'infrastructure de staging ou de production pour travailler avec un système « vivant ». C'est une grande chance si le client dispose d'outils de surveillance de l'infrastructure et des performances. Nous parlerons de ces outils dans la section suivante.
Documentation. Si le client a de la documentation, c'est un bon début. Elle peut être obsolète, mais c'est tout de même un bon point de départ. Ne croyez jamais la documentation - vérifiez-la avec le client, sur l'infrastructure réelle et dans le code source.
Processus d'évaluation de l'architecture
Comment traiter un tel volume d'informations en si peu de temps ? Tout d'abord, parallélisez le travail.
Le DevOps devrait jeter un œil à l'infrastructure. Le Tech Lead dans le code. L'ingénieur en performance devrait examiner les métriques de performance. Le spécialiste des bases de données devrait approfondir les structures de données.
Mais c'est le cas idéal, lorsque vous avez beaucoup de ressources. En général, l'évaluation d'un projet est réalisée par une à trois personnes. Vous pouvez même effectuer l'évaluation vous-même, ce qui se produit souvent si vous avez les connaissances et l'expérience nécessaires dans tous les domaines du projet. Dans ce cas, vous devez automatiser tous les processus autant que possible.
Malheureusement, vous devrez lire la documentation manuellement. Avec une expérience adéquate, vous pourrez assez rapidement évaluer la qualité de la documentation. Ce qui est vrai et ce qui ne correspond pas à la réalité. Parfois, vous pouvez rencontrer une architecture dans la documentation qui ne fonctionnera jamais dans la réalité. C'est un déclencheur pour vous interroger sur la manière dont cela fonctionne réellement dans le projet.
Outils utiles pour l'automatisation de l'évaluation des projets
L'évaluation du code est un exercice simple. Vous pouvez utiliser des analyseurs de code statiques qui mettront en évidence les problèmes de conception, de performance et de sécurité. Voici quelques-uns d'entre eux :
est un excellent outil pour les architectes. Il vous montrera une vue d'ensemble, la dépendance entre les modules et les domaines potentiels de refactorisation. Comme tous les bons outils, il coûte cher, mais vous pouvez profiter d'une version d'essai de 30 jours.
est un bon vieil outil. Un outil d'analyse statique de code. Il permet d'identifier le mauvais code, les bogues et 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, c'est . Pour Azure, c'est simplement .
Une surveillance supplémentaire des performances et de la journalisation aidera à identifier les problèmes de performance à tous les niveaux. Des bases de données avec des requêtes inefficaces au backend, jusqu'au frontend. Même si le client n'a pas installé ces outils au préalable, vous pouvez les intégrer assez rapidement dans le système existant pour identifier les problèmes de performance.
Comme toujours, de bons outils ont un coût. Je peux vous recommander quelques outils payants. Bien sûr, vous pouvez utiliser des solutions open-source, mais cela vous demandera plus de temps. Et cela doit être fait à l'avance, et non lors de l'évaluation de l'architecture.
est un outil d'évaluation des performances des applications
est un service cloud de surveillance des systèmes
Il existe de nombreux outils pour tester la sécurité. Cette fois, je vous recommande un outil gratuit pour scanner le système.
est un outil pour scanner les applications web conformément aux normes de sécurité.
Rassemblons le tout.
Préparez le rapport
Commencez votre rapport par les données collectées auprès du client. Décrivez les objectifs du projet, les contraintes, les exigences non fonctionnelles. Ensuite, mentionnez toutes les données d'entrée comme le code source, la documentation et l'infrastructure.
Étape suivante. Indiquez tous les problèmes que vous avez trouvés manuellement ou à l'aide d'outils automatisés. Placez les grands rapports générés automatiquement à la fin dans la section des annexes. Ici, vous devez fournir des preuves brèves et concises des problèmes identifiés.
Priorisez les problèmes identifiés sur une échelle de error, warning, info. Vous pouvez choisir votre propre échelle, mais celle-ci est largement acceptée.
En tant que véritable architecte, vous devez fournir des recommandations pour résoudre les problèmes trouvés. Décrivez les améliorations et la valeur pour l'entreprise que le client obtiendra. Comment montrer la valeur pour l'entreprise de que nous avons discuté précédemment.
Préparez une feuille de route avec de petites itérations. Chaque itération doit inclure le temps nécessaire, une description, le nombre 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.
Ne vous contentez jamais d'envoyer simplement le rapport par email. Il peut soit ne pas être lu du tout, soit être lu sans compréhension adéquate sans explications appropriées. En résumé, la communication en direct aide à éliminer les malentendus entre les personnes. Vous devriez organiser une réunion avec le client et discuter des problèmes identifiés en mettant l'accent sur les plus significatifs. Attirez l'attention du client sur les problèmes dont il n'avait peut-être même pas connaissance, comme les problèmes de sécurité, et expliquez comment ils peuvent affecter les affaires. Montrez votre feuille de route avec des améliorations et discutez des différentes options plus adaptées au client. Cela peut inclure le temps, les ressources, ou le volume de travail.
Comme conclusion de votre réunion, envoyez au client votre rapport.
En conclusion
L'évaluation de l'architecture est un processus complexe. Pour effectuer l'évaluation correctement, vous devez avoir suffisamment d'expérience et de connaissances.
C'est réalisable - fournir des résultats utiles au client et à son entreprise en seulement une semaine. Même si vous le faites seul.
D'après mon expérience, de nombreuses améliorations étaient abandonnées à mi-chemin, et parfois elles n'ont même jamais commencé. Ceux qui optaient pour un juste milieu et réalisaient certaines améliorations maximales utiles pour l'entreprise avec un minimum d'efforts augmentaient considérablement la qualité de leur produit. Ceux qui ne faisaient rien pouvaient, après quelques années, même devoir fermer leur projet.
Votre objectif est de montrer au client les meilleures améliorations au meilleur prix.
D'autres articles de la section peuvent être lus pendant votre temps libre.
Je vous souhaite du code propre et de bonnes solutions architecturales.
Notre groupe Facebook — .
Source : habr.com
