Que votre architecture vive dans la PR, pas dans le wiki.
Activez dans le panneau les règles qui comptent et ajustez-les par projet ; elles s'appliquent à chaque PR, vos décisions deviennent des ADR numérotés et la carte des dépendances montre la réalité.
Six situations qui reviennent sans cesse dans ce rôle, et ce qu'AppArch fait pour chacune.
01
Les règles existent, personne ne les applique
Les règles d'architecture ont été soigneusement rédigées dans le wiki il y a deux ans. La plupart des arrivants depuis n'ont jamais ouvert cette page.
Ce que fait AppArch
Une règle activée dans le panneau s'exécute sur chaque merge request, dans n'importe lequel des neuf langages, signale la violation sur sa propre ligne et explique pourquoi, même pendant vos vacances.
« Pourquoi a-t-on fait ça comme ça ? » reste sans réponse
Un nouvel arrivant demande pourquoi le service parle à la file de cette façon. La personne qui a pris cette décision est partie l'an dernier.
Ce que fait AppArch
Le module ADR numérote chaque décision, la suit tout au long du cycle de vie MADR et relie chaque décision remplaçante à celle qu'elle remplace. Le raisonnement reste dans le produit, pas dans une tête.
Le schéma d'architecture a été dessiné pour la réunion de lancement. Le code a pris son propre chemin quelques mois plus tard.
Ce que fait AppArch
La carte des dépendances d'ArchScan est construite à partir du code : cycles, violations de couches et fuites montrent ce qui est, pas ce qui était prévu. La dérive se voit avant de s'accumuler.
Cinq équipes, cinq lectures de la même règle de couches, et dans chaque revue le même débat sur la bonne.
Ce que fait AppArch
Les règles sont définies une fois pour l'espace de travail et ajustées par projet seulement s'il y a une vraie raison. L'exception est écrite une fois au lieu d'être rediscutée à chaque revue.
Activez une nouvelle règle sur une base de code de dix ans et le backlog se remplit du jour au lendemain de milliers de constats. En une semaine, l'équipe demande de la désactiver.
Ce que fait AppArch
ArchPilot ne commente que les lignes modifiées par une merge request : la dette existante reste hors de la revue. Le réglage fail-on décide quelle sévérité fait échouer le build : commencez par critique et resserrez à mesure que la dette diminue.
Deux écritures sans transaction, une recherche utilisée sans vérification : du code qui semble correct en revue et casse à la première requête inhabituelle.
Ce que fait AppArch
SmartScan suit chaque point d'entrée jusqu'à la base de données et liste ce qui peut casser en chemin : une recherche vide, une écriture partielle, une faille de contrat. Chaque risque arrive avec son chemin complet, son fichier et sa ligne.
Tableau de bord ArchScanLa santé de l'architecture sur l'ensemble du parc : projets audités, score moyen, problèmes ouverts et répartition des notes.Décisions d'architectureDes registres de décisions numérotés, avec statut, étiquettes et projet concerné.Santé du codeOù se trouve vraiment la dette : méthodes à haut risque, fichiers qui concentrent les constats et retard des dépendances.
Nous utilisons des cookies pour améliorer votre expérience, analyser le trafic et mesurer l'efficacité de nos annonces. Les cookies d'analyse et publicitaires ne sont activés qu'avec votre accord. Politique de confidentialité