L’architecte et Git : une fusion de raison

L’architecte, survivance du passé ?

L’architecte est souvent un rôle incompris ou mal compris. Entre l’architecture, la conception – “design” – et le développement les frontières sont devenues d’autant plus floues que les outils modernes permettent d’obtenir en quelques clics et quelques instants des structures de base évoluées, à la fois performantes et résilientes, et même déjà connectées. D’autant plus floues, également, que le mot “design” est aujourd’hui utilisé dans de nombreux domaines : functional design, user experience design, domain-driven design, design thinking, et tous les “-by design” du marché.

Dans ce flou croissant, reflet d’un déplacement de la complexité, j’ai gardé une vision du rôle de l’architecte qui, je crois, ne se dément toujours pas : il est celui qui fait le premier lien entre un existant et un futur souhaité.

Illustration : Votre système existant (“legacy”, merci les OPS), votre système rêvé et votre utilisateur rêvé.

Plus spécifiquement, l’architecte devrait aider l’équipe à décider quelles contraintes prendre en compte pour sa future solution. Il y a un corollaire non trivial, puisque la future solution devient un jour la solution existante, à son tour base d’une nouvelle future solution : l’architecte devrait connaître quelle architecture l’équipe a réellement mise en place.

Votre future solution peut être complètement hors-sol (si vous aimez le risque), complètement intégrée dans le système existant (si vous aimez les contraintes), ou bien un mix des deux (si vous aimez les prises de tête). Quelle que soit la configuration, à mon sens ce rôle est toujours d’actualité, même si les technologies et les façons de faire ont été révolutionnées depuis les grands systèmes monolithiques. Cette vision est aussi valable pour l’architecte d’entreprise (plutôt urbaniste) mais c’est plutôt de l’architecte applicatif dont nous parlons ensuite.

“Ok, je comprends mieux son rôle, mais quel rapport avec Git ?”

Une communication absente sur un sujet non partagé

Face à ces enjeux, l’architecte “tour d’ivoire” est un piège qui se referme non pas sur l’architecte isolément mais sur l’ensemble du système. Exemples de verbatims :

  • “Les développeurs n’ont pas lu la documentation”, “ils n’ont pas suivi l’architecture définie”
  • “Les architectes ont défini des solutions inapplicables”, “le document est inaccessible”, “personne n’a compris cette partie-là”

Illustration : La tour d’ivoire n’est pas le produit.

Le problème ici est double :

  1. La communication est défaillante : compliquée, voire inexistante
  2. Le sujet de cette communication n’est pas partagé : ni le contenu, ni la forme

Vous noterez aussi que l’architecte comme « DO-er » (donc cochon) à l’extérieur de l’équipe est un anti-pattern agile : celui-ci est parfois imposé contractuellement ou organisationnellement en phase de transition. La maturité Agile des acteurs peut éventuellement améliorer le premier point en favorisant une communication fréquente et adaptée, l’idéal étant que l’architecte en question intègre l’équipe, au moins pour les itérations où cela est nécessaire. En revanche, le second point restera toujours un obstacle nécessitant beaucoup d’efforts pour être franchi.

C’est là que Git rentre en jeu.

Git, outil de partage effectif

Depuis 10 ans, Git s’est imposé comme gestionnaire de version dans le monde du développement logiciel. Cela fait plusieurs années que je n’ai plus entendu parler de SVN que comme un souvenir (même s’il reste utilisé, mais ce n’est pas l’objet ici). L’intérêt principal d’un gestionnaire de version, et de Git en particulier, est qu’il permet de maîtriser les évolutions depuis une situation de départ vers une situation d’arrivée, ce qui est particulièrement avantageux dans une approche itérative et incrémentale, notamment grâce à deux mécanismes :

  1. La protection de l’existant par la création d’une branche pour créer un futur alternatif potentiel (branch)
  2. La décision de modifier l’existant par la conjonction (la ligature, en gardant la métaphore horticole) de la branche (merge)

Illustration : Branching et merging dans Git.

Si l’un des facteurs de succès de Git est son architecture totalement décentralisée; chaque contributeur disposant en local de toute l’histoire du repository (tout ce qui est fait sur le code source de l’application), ce n’est pas ce qui nous intéresse ici : c’est la facilité qu’offre Git pour faire de la relecture et inciter à l’échange en partageant un outil et une façon de l’utiliser que nous allons mettre à profit dans le cadre de la création et de l’évolution de l’architecture d’une application.

En effet, Git est l’outil rêvé pour que des personnes tenant ce rôle d’architecte travaillent sur le futur tout en étant ancrées dans l’existant, et pour prendre des décisions officielles et transparentes, et plus particulièrement LE Git de l’application concernée. Cette approche est largement inspirée par une conférence de Alain Helaili à LKFR.

Illustrons ceci par un exemple, simplifié à des fins didactiques.

Le projet ARCHIGIT

Note : Ceux qui développent avec Git n’apprendront rien ici, c’est surtout pour illustrer la démarche avec un sujet d’architecture.

Votre équipe est recrutée pour répondre au besoin d’acteurs de la logistique.

Illustration : Création d’un repository tout nouveau.

Nous ajouterons un README.md pour préciser l’objectif de l’équipe tel qu’il est connu, ce qui permet au passage d’initier le repository.

La 2e question après l’objectif sera : quelles seront les bases de notre future solution ? Dans Git, une question c’est une branche et une pull request associée :

Question = Branche + Pull request (ou Merge Request dans Gitlab, que j’utilise ci-dessous)

Q = B + PR

Illustrations : Création d’une branche…

Illustration : … et d’une merge request.

Vous remarquerez au passage que l’équipe suit la bonne pratique d’indiquer dans le champ description de sa MR sa TODO liée à la branche.

L’équipe dispose donc bien :

  1. D’un existant qu’elle cherche pour l’instant à préserver
  2. D’un projet de modification de l’existant

Illustration : Branches actives.

Au cours d’un atelier d’Event Storming, l’équipe identifie 3 domaines initiaux :

  • Les commandes
  • L’acheminement
  • Les stocks

Un membre de l’équipe met à jour le repository pour préparer ces domaines.

Illustration : Ajout de la nouvelle structure.

Après un échange de commentaires dans la MR et un accord des contributeurs, l’équipier met à jour le README.md, à la racine puisque c’est la structure initiale, ce qui nous donne une page d’accueil cohérente :

Illustration : Racine du repository sur la branche.

Une fois que tous les commentaires ont été pris en compte, le préfixe « WIP: » est enlevé et la branche est mergée dans le master.

Illustration : Histoire de la structure du repository.

Quelques pratiques complémentaires

L’ADR : Architecture Decision Record

Vous l’avez vue passer ? Eh oui, dans cette approche, un merge est une ADR (ou « Enregistrement de décision sur l’architecture »), et même une LADR (Light ADR). Simple, élégant, efficace, refaire l’historique des ADR d’un projet devient un jeu d’enfant. Mais alors, que faire du Dossier d’Architecture Technique de 200 pages qu’on avait commencé il y a un an dans un document Word que presque personne n’a ouvert ?…

Retrouver ses petits

Les commits liés à l’architecture seront bien sûr largement minoritaires, un petit préfixe “archi-” vous aidera à y voir plus clair. Il est possible aussi que vous ayez besoin d’ajouter quelques répertoires pour compléter les descriptions (le markdown ayant ses limites).

La bonne démarche

Globalement, vos todo pour une nouvelle branche ressembleront à celle de l’exemple :

  • Faire (au moins) un atelier
  • Traduire le résultat dans Git
  • Ecrire ou modifier un README.md au bon endroit
  • Intégrer les remarques

Le “transverse”

Quand j’entends “c’est transverse”, mon radar à inaction se met en alerte, un peu comme quand j’entends “gérer”, “saisir” ou “enregistrer” pour des user stories (quel utilisateur VEUT enregistrer quoi que ce soit ?!). C’est un peu comme de dire que le coeur est transverse pour tous les humains, ce n’est pas faux mais ça n’enlève pas que :

  1. Il y a des caractéristiques générales
  2. Il n’y a que des cas particuliers

En agile ou en lean, on parle de STANDARD ou de DEFINITION OF DONE. Donc généralement ça se met à la racine, et on précise l’implémentation là où on en a besoin.

L’essentiel n’est pas l’outil…

… Mais ce que les individus en font. Dans notre cas, il est intéressant de regarder en quoi l’outil permet de faciliter ou d’améliorer le travail des acteurs et leurs interactions, en gardant à l’esprit que rien ne remplace la conversation en face-à-face.

Une source unique de vérité

Quel qu’ait été votre rôle, souvenez-vous de la dernière fois où vous êtes arrivé dans une équipe projet. Souvenez-vous du temps qu’il vous a fallu pour obtenir les droits d’accès au repository, les droits d’accès à l’outil de gestion de documents, souvenez-vous de la chasse aux documents, à la bonne version des documents ou plutôt de la dernière version des documents, aux mails qui expliquent qui a dit quoi sur quel sujet, souvenez-vous de la traque des arguments expliquant une décision ou une autre, le code sous les yeux qui ne correspond pas du tout aux autres documents…

En utilisant le même outil, non seulement vous simplifiez la compréhension de l’histoire de votre produit mais en plus vous utilisez des compétences d’utilisation qui vous permettent de mieux comprendre pourquoi cette histoire s’est écrite ainsi, à la manière d’un artisan qui acquiert le bon geste du groupe qu’il intègre, tout en gardant la possibilité d’apporter sa propre expérience à ce geste dans le futur.

Illustration : L’historique de la structure d’un message d’échange dans un projet réel Octo.

Ceci est d’autant plus pertinent, voire obligatoire, qu’architectes et développeurs parlent du même objet : le produit. Partant, ce principe est pertinent pour tous les types de contribution au produit, tests de recette, documentation, commercialisation…

Une décision qui résulte d’une discussion

Comme déjà vu plus haut, la décision se traduit par un merge, mais Git propose deux fonctionnalités qui facilitent à la fois la discussion et la focalisation de cette discussion “juste sur le changement” : le “diff” et la requête.

En effet, un avantage crucial dans la rapidité de traitement des changements est, pour un contributeur, de les identifier en un coup d’oeil, et surtout de le faire de la même manière que partout ailleurs dans le code, comme d’habitude. Les changements étant repérés plus facilement et plus rapidement, les discussions s’initient plus facilement et surtout plus pertinemment.

Ensuite, l’utilisation d’une “requête” (Pull Request ou Merge Request) avant de décider d’intégrer les modifications sur la branche de référence est une politesse qui :

  • suscite la discussion,
  • encourage l’appropriation,
  • améliore la responsabilisation.

Illustration : La publication de la Merge Request a permis d’améliorer et d’accélérer la compréhension de l’architecture par l’équipe de développement ! Illustration reprise du même projet Octo.

Cette focalisation permet aux changements d’être traités et surtout d’être compris plus efficacement, en améliorant la circulation de l’information et la responsabilité collective, avec un effet induit de maîtrise des tensions au sein de l’équipe.

Une architecture pilotée

Enfin, l’interface de travail fournie par des Gitlab ou Github structure l’information et vous permet de saisir en un coup d’oeil les éléments de travail quotidien.

Illustration : Une interface bien connue des développeurs. Il n’y a plus qu’à :)

Il est très intéressant qu’en plus ce travail soit non seulement vu et perçu de tous (pas de travail en sous-marin, officieux) mais aussi structuré de la même manière. Dans un sens (architecture vers développement du produit) comme dans l’autre le langage est le même et les habitudes de travail très proches.

Git, le nouvel outil de l’architecte

En résumé, Git propose :

  • des mécanismes qui sont hautement intéressants pour le travail de l’architecte,
  • un espace de travail commun à celui de l’équipe de développement.

En l’utilisant, l’architecte s’assure que sa démarche est ancrée dans la réalité, bien sûr, mais il diminue aussi la complexité du système d’information de la future solution en évitant de multiplier les outils et les sources d’information. C’est là où un nouvel arrivant pourra consulter tout ce qui s’est fait, comprendre le comment du pourquoi de chaque décision et de la structure existante du code, voir quels sont les sujets en cours de discussion.

Un dernier effet vertueux, non négligeable, est de rapidement acculturer ses interlocuteurs aux mécanismes de pensée de l’équipe de développement, ce qui atténuera l’effet des biais culturels entre celle-ci et les autres acteurs du système.

Et vous, comment votre architecte fait-il pour embarquer les équipes de développement de votre futur produit ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


Ce formulaire est protégé par Google Recaptcha