Garder un modèle à jour

L'explication habituelle est la discipline, et elle est fausse. Les mêmes ingénieurs qui laissent un modèle dériver pendant deux ans gardent leur suite de tests au vert tous les jours, et la différence ne tient pas à leur degré d'attention - elle tient à ce qu'un test en échec arrête la chaîne et un diagramme faux n'arrête rien.

Le code est entouré d'une machinerie qui force l'attention sur lui au moment où il change : un compilateur, une exécution de tests, un relecteur qui doit approuver. Un modèle dans un wiki n'a rien de tout cela. Rien, sur le chemin du ticket à la production, n'oblige qui que ce soit à ouvrir la page, donc rien ne fait jamais remonter le désaccord. Le modèle ne se dégrade pas - le système bouge, et le modèle reste exactement où il était.

Tout dispositif qui fonctionne a la même forme : le modèle est placé là où une étape existante va le percuter.

Mettez la vue dans le dépôt. Un diagramme versionné en Mermaidà côté du code apparaît dans le diff dès que son fichier est touché, et il est lu par la personne qui relit la modification. C'est le seul mécanisme de cette liste dont le maintien ne coûte rien, parce que la relecture avait déjà lieu.

Référencez les vues depuis les décisions d'architecture.Un court enregistrement de décision qui pointe vers la vue montrant la structure qu'il a arrêtée fait que cette vue est ouverte chaque fois que quelqu'un demande pourquoi la structure est ainsi - c'est-à-dire précisément au moment où le fait qu'elle soit fausse compterait.

Faites du modèle la source de quelque chose dont on a besoin.Si la vue de déploiement engendre le diagramme du runbook, ou si le modèle de domaine engendre le glossaire dans lequel le support cherche, alors quelqu'un s'en aperçoit en quelques jours plutôt qu'en quelques trimestres.

L'autre moitié de la réponse, c'est que la plupart des modèles sont trop gros pour être tenus à jour, et aucun processus n'y remédie. Si maintenir le modèle prenait un jour par mois et que l'équipe dispose d'une heure, le modèle périmera quelle que soit l'organisation de la revue - le geste honnête est donc de le tailler à cette heure.

C'est le même test que pour le cadrage, appliqué plus tard : les vues incapables de nommer une décision sont celles qu'on abandonne, et les abandonner n'est pas une perte puisqu'elles n'étaient pas lues. Ce qui reste est assez petit pour qu'on remarque qu'il est faux.

Ensuite, supprimez vraiment le reste.C'est l'étape que les gens ne franchissent pas, et celle dont l'arithmétique est la plus claire. Un diagramme manquant coûte à un lecteur dix minutes de questions ; un diagramme faux avec aplomb lui coûte une journée et, s'il n'a pas de chance, une décision prise dessus. Une documentation que vous n'entretiendrez pas n'est pas neutre, c'est un piège au logo de votre équipe.