Service:Service

Architecture & Clean Code

Cadrage technique, Architecture Decision Records, revues de code et standards durables à l'échelle de l'équipe.

Ce que nous livrons

ADR, diagrammes C4
Standards de code (lint, format)
Revues de code, pair programming
Formation continue

DDDSOLIDHexagonal

Discuter de ce besoin Voir des réalisations

L'architecture d'un logiciel n'est pas un diagramme. C'est l'ensemble des décisions qu'il sera coûteux de changer plus tard, et la plupart d'entre elles sont prises sans qu'on s'en aperçoive, dans une conversation de couloir ou un commit du vendredi soir. Le travail consiste moins à choisir ces décisions qu'à les rendre visibles au moment où on les prend.

Cette prestation s'adresse aux équipes qui existent déjà et qui produisent. Nous n'arrivons pas avec un modèle à appliquer. Nous cadrons ce qui doit l'être, nous écrivons ce qui doit être écrit, et nous laissons derrière nous des habitudes qui tiennent quand nous ne sommes plus là. C'est le seul critère de réussite qui nous intéresse.

Comment nous travaillons

Les ADR, ou pourquoi on écrit les décisions

Un Architecture Decision Record tient sur une page : le contexte, la décision, les options écartées et leurs raisons, les conséquences acceptées. Cela paraît bureaucratique jusqu'au jour où quelqu'un demande pourquoi on a choisi cette file de messages plutôt qu'une autre, et que les trois personnes présentes à la réunion sont parties.

L'intérêt principal n'est pas l'archive, il est dans l'écriture elle-même. Rédiger les options écartées oblige à les avoir considérées. Nous avons vu plusieurs décisions changer pendant la rédaction de leur propre ADR, simplement parce que mettre les raisons noir sur blanc a montré qu'elles ne tenaient pas.

Les diagrammes C4, à la bonne échelle

Le modèle C4 propose quatre niveaux de zoom, du contexte général jusqu'au code. Dans la pratique, deux suffisent presque toujours : le diagramme de contexte, qui montre votre système et ce qui l'entoure, et le diagramme de conteneurs, qui montre les applications, les bases et les files. Les niveaux plus fins se périment en quelques semaines et personne ne les met à jour.

Nous produisons donc deux diagrammes maintenus plutôt que quinze abandonnés. Un schéma faux est pire qu'un schéma absent : le second oblige à aller lire le code, le premier envoie confiant dans la mauvaise direction.

Revues de code et pair programming

Une revue de code qui se contente de commenter le formatage est du temps perdu, et le formatage devrait être automatique de toute façon. Une revue utile porte sur trois questions : est-ce que ça résout le bon problème, est-ce que quelqu'un d'autre pourra le reprendre dans six mois, et qu'est-ce qui casse si cette hypothèse est fausse. Nous formons les équipes à poser ces questions-là.

Le pair programming, nous l'utilisons par séquences courtes et sur les sujets difficiles, pas en permanence. Deux personnes sur un CRUD, c'est du gaspillage. Deux personnes sur la conception d'un moteur de règles métier, c'est la moitié du temps de débogage économisé et une deuxième personne qui comprend le système. Nous mesurons cette bascule à l'usage et nous l'ajustons avec l'équipe.

Ce qui amène ici

Les mêmes débats techniques reviennent tous les trimestres sans jamais être tranchés.
Chaque développeur a sa façon de structurer un module, et l'onboarding prend deux mois.
Vous avez doublé l'effectif technique en un an et la cohérence s'est perdue en route.
Personne ne sait dire pourquoi telle brique a été choisie, ni si elle est encore justifiée.

Quand ce n'est pas la bonne prestation

Si votre équipe tient en deux personnes qui travaillent ensemble depuis cinq ans, cette prestation vous apportera peu. Vos décisions sont déjà partagées, elles le sont juste oralement, et formaliser ce qui fonctionne coûte plus qu'il ne rapporte. Revenez nous voir le jour où vous recrutez la troisième et la quatrième personne : c'est là que l'oral cesse de suffire.

Nous le disons avant de commencer, pas après.

Qualité mesurée

Tests automatisés écrits pendant le développement, pas après. Revue de code obligatoire avant toute fusion, y compris sur les correctifs d'une ligne. Analyse statique branchée sur la CI : si la couverture baisse ou qu'une vulnérabilité connue apparaît, la chaîne s'arrête et personne ne passe outre.

Livraison continue

Un environnement de recette déployé à chaque fusion, une démo à la fin de chaque itération, et un tableau d'avancement que vous consultez quand vous voulez sans avoir à le demander. Les mauvaises nouvelles arrivent tôt, quand il reste du temps pour décider quoi faire.

Transfert de savoir

Nous partons du principe que vous reprendrez la main. Les décisions d'architecture sont écrites et datées, la documentation vit dans le dépôt à côté du code, et vos développeurs travaillent en binôme avec les nôtres s'ils le souhaitent. À la fin, le code, les accès et l'historique vous appartiennent.

Aller plus loin:Service[3]

Un projet en tête ? Donnons-lui vie.

Dites-nous ce que vous cherchez à construire ou à reprendre. Réponse sous 24 heures ouvrées, sans engagement, et un avis franc sur la faisabilité même si la réponse ne nous arrange pas.

Discuter de ce besoin Voir les réalisations