Au début, il est toujours difficile de comprendre un projet vaste et ancien. L'architecture est l'une des activités d'une évaluation d'architecte. Habituellement, vous devez travailler sur de grands et anciens projets et les résultats doivent être livrés en une semaine.
Comment évaluer un projet de 100 XNUMX lignes de code ou plus en une semaine tout en fournissant des résultats vraiment utiles au client.
La plupart des architectes et des responsables techniques ont été confrontés à des évaluations de projets similaires. Cela peut ressembler à un processus semi-formel ou à un service distinct comme cela se fait dans notre entreprise, d'une manière ou d'une autre, la plupart d'entre vous ont géré ce problème.
L’original en anglais pour vos amis non russophones est ici : .
L'approche de notre entreprise
Je vais vous expliquer comment cela fonctionne dans notre entreprise et comment j'agis dans des situations similaires, mais vous pouvez facilement modifier 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 architecturale pour plusieurs raisons :
- L'équipe pense que son projet est parfait et c'est suspect. Nous avons eu de tels cas, et souvent, dans de tels projets, tout est loin d'être idéal.
- L'équipe souhaite tester son projet et ses solutions.
- L’équipe sait que les choses vont mal. Ils peuvent même énumérer les principaux problèmes et causes, mais souhaitent obtenir une liste complète des problèmes et des recommandations pour améliorer le projet.
Externe est un processus plus formel qu’une évaluation interne. Le client ne vient toujours que dans un cas, lorsque tout va mal, très mal. Habituellement, le client comprend qu'il existe des problèmes globaux, mais ne peut pas identifier correctement les causes et les décomposer en composants.
L'évaluation d'une architecture pour 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, comprenant les principaux problèmes et les recommandations d'amélioration. Par conséquent, si nous traitons de l’évaluation externe du projet, l’évaluation interne sera un jeu d’enfant. Considérons le cas le plus difficile.
Évaluation de l'architecture de projet d'entreprise
Un projet typique à évaluer est un grand et ancien projet d’entreprise présentant de nombreux problèmes. Un client vient nous voir et nous demande de régler son projet. C’est comme avec un iceberg, le client ne voit que la pointe de ses problèmes et n’a aucune idée de ce qu’il y a sous l’eau (au fond du code).
Problèmes dont le client peut se plaindre et dont il peut avoir connaissance :
- Les problèmes de performance
- Problèmes d'utilisabilité
- Déploiement à long terme
- Manque de tests unitaires et autres
Problèmes dont le client n'est probablement pas conscient, mais qui peuvent être présents dans le projet :
- Problèmes de sécurité
- Les problèmes de conception
- Mauvaise architecture
- Erreurs algorithmiques
- Technologies inappropriées
- Dette technique
- Mauvais processus de développement
Processus formel de révision de l’architecture
Il s'agit d'un processus formel que nous suivons en tant qu'entreprise, mais vous pouvez le personnaliser en fonction de votre entreprise et de votre projet.
Demande d'un client
Le client demande à évaluer l'architecture du projet en cours. La personne responsable de notre côté collecte les informations de base sur le projet et sélectionne les experts nécessaires. Selon le projet, il peut s'agir de différents experts.
Solution Architect – le principal responsable de l’évaluation et de la coordination (et souvent le seul).
Empiler des experts spécifiques – .Net, Java, Python et autres spécialistes techniques selon le projet et les technologies
Experts du cloud – il peut s’agir d’architectes cloud Azure, GCP ou AWS.
Infrastructure – DevOps, Administrateur système, etc.
Autres spécialistes – comme le big data, l’apprentissage automatique, l’ingénieur 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 méthodes de communication par courrier. Le moyen le plus inefficace.
- Réunions en ligne.
- Des outils particuliers d'échange d'informations tels que : Google doc, Confluence, référentiels, etc.
- Réunions « live » sur place. Le moyen le plus efficace et le plus coûteux.
Que devez-vous obtenir du client ?
Informations de base. De quoi parle le projet? Son but et sa valeur. Principaux objectifs et projets pour l'avenir. Objectifs et stratégies commerciales. Principaux problèmes et résultats souhaités.
Informations sur le projet. Pile 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 conception ont été utilisés.
Prérogatives non fonctionnelles. Toutes les exigences liées aux performances, à la disponibilité et à 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 avoir accès aux référentiels et à la documentation sur la façon de construire le projet.
Accès aux infrastructures. Ce serait bien d’avoir accès à la scène ou à l’infrastructure de production pour travailler avec le système live. C'est une grande réussite 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 dispose de documentation, c'est un bon début. C'est peut-être dépassé, mais c'est quand même un bon début. Ne faites jamais confiance à la documentation - testez-la avec le client, sur une infrastructure réelle et dans le code source.
Processus d'évaluation de l'architecture
Comment peut-on traiter une telle quantité d’informations en si peu de temps ? Tout d’abord, parallélisez le travail.
DevOps devrait examiner l'infrastructure. La technologie mène au code. Ingénieur de performance pour afficher les mesures de performance. Un spécialiste des bases de données doit approfondir ses connaissances sur les structures de données.
Mais c’est un cas idéal lorsque vous disposez de beaucoup de ressources. En règle générale, une à trois personnes évaluent un projet. Vous pouvez même réaliser l’estimation vous-même, ce qui est souvent le cas si vous possédez les connaissances et l’expérience appropriées 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 la bonne expérience, vous pouvez rapidement comprendre la qualité de la documentation. Ce qui est vrai et ce qui ne coïncide clairement pas avec la réalité. Parfois, vous verrez dans la documentation une architecture qui ne fonctionnera jamais dans la vraie vie. C’est un déclencheur pour vous de réfléchir à la façon dont cela a été fait en réalité dans le projet.
Outils utiles pour automatiser l’évaluation des projets
L'évaluation du code est un exercice simple. Vous pouvez utiliser des analyseurs de code statiques qui vous montreront les problèmes de conception, de performances et de sécurité. En voici quelques-uns :
est un excellent outil pour un architecte. Il vous montrera une vue d'ensemble, les dépendances 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.
- un bon vieil outil. Un outil pour l'analyse de code statique. Vous permet d'identifier les mauvais codes, 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 de bien évaluer l’efficacité de votre infrastructure en termes de coût et de performances. Pour AWS, c'est . C'est facile pour Azure .
Une surveillance et une journalisation supplémentaires des performances aideront à détecter les problèmes de performances à tous les niveaux. En commençant par une base de données avec des requêtes inefficaces, le backend et en terminant par le frontend. Même si le client n'a pas installé ces outils auparavant, vous pouvez les intégrer assez rapidement au système existant pour identifier les problèmes de performances.
Comme toujours, les bons outils en valent la peine. Je peux recommander quelques outils payants. Bien sûr, vous pouvez utiliser l'open source mais cela vous prendra plus de temps. Et cela doit être fait dès le départ, et non pendant le processus d’évaluation architecturale.
– un outil d’évaluation des performances des applications
– service de surveillance du système cloud
Il existe de nombreux outils disponibles pour les tests de sécurité. Cette fois, je vous recommanderai un outil d'analyse du système gratuit.
– un outil d’analyse des applications Web pour vérifier leur conformité aux normes de sécurité.
Rassemblons tout en un tout.
Préparation d'un rapport
Commencez votre rapport avec les données que vous avez collectées auprès du client. Décrire les objectifs du projet, les contraintes et les exigences non fonctionnelles. Après cela, toutes les données d'entrée doivent être mentionnées : code source, documentation, infrastructure.
L'étape suivante. Répertoriez 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 applications. Il doit y avoir des preuves brèves et succinctes des problèmes détectés.
Hiérarchiser les problèmes rencontrés sur l'échelle d'erreur, d'avertissement, d'information. Vous pouvez choisir votre propre échelle, mais celle-ci est généralement acceptée.
En tant que véritable architecte, il est de votre responsabilité de formuler des recommandations pour corriger les problèmes constatés. Décrivez les améliorations et la valeur commerciale que le client recevra. Comment montrer la valeur commerciale de nous en avons discuté plus tôt.
Préparez une feuille de route avec de petites itérations. Chaque itération doit contenir le temps nécessaire pour terminer, une description, la quantité de ressources nécessaires à l'amélioration, la valeur technique et la valeur commerciale.
Nous complétons l’évaluation de l’architecture et fournissons au client un rapport
Ne vous contentez jamais d’envoyer un rapport par courrier. Il se peut qu’il ne soit pas lu du tout, ou qu’il ne soit pas lu et compris sans explication appropriée. Bref, la communication en direct permet d’éliminer les malentendus entre les personnes. Vous devez planifier une réunion avec le client et parler des problèmes rencontrés, en vous concentrant sur les plus importants. Il convient d’attirer l’attention du client sur des problèmes dont il n’a peut-être même pas conscience. Tels que les problèmes de sécurité et expliquez comment ils pourraient avoir un impact sur l'entreprise. Montrez votre feuille de route avec des améliorations et discutez des différentes options plus adaptées au client. Cela peut être du temps, des ressources, de la quantité de travail.
En guise de résumé de votre réunion, envoyez votre rapport au client.
En conclusion
L'évaluation de l'architecture est un processus complexe. Pour mener à bien l’évaluation, vous devez disposer de suffisamment d’expérience et de connaissances.
Il est possible de 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 démarré. Ceux qui ont choisi le juste milieu pour eux-mêmes et n'ont apporté qu'une partie des améliorations les plus utiles à l'entreprise avec des coûts de main-d'œuvre minimes ont considérablement amélioré la qualité de leur produit. Ceux qui n’ont rien fait pourraient mettre un terme au projet après quelques années.
Votre objectif est de montrer au client un maximum d’améliorations pour le prix minimum.
Autres articles de la rubrique vous pouvez lire à votre guise.
Je vous souhaite un code propre et de bonnes décisions architecturales.
Notre groupe Facebook - .
Source: habr.com