Idées
Qu’est-ce qui rend une base de code capable d’évoluer?
L’évolutivité se mesure en pratique, pas sur un schéma. Cinq traits sans éclat des bases de code qui vieillissent bien
«Capable d’évoluer» n’est pas une propriété qu’on lit sur un schéma d’architecture. C’est une propriété qu’on mesure en faisant: combien de temps prend un changement ordinaire, combien de fichiers touche-t-il, à quel point êtes-vous sûr de n’avoir rien cassé ?
Les bases de code que j’ai vues bien vieillir partagent quelques traits, et aucun n’est spectaculaire.
Des frontières qui suivent le métier. Quand un changement dans un concept métier atterrit à un seul endroit, le code peut absorber le suivant. Quand il atterrit à six endroits, chacun est une occasion d’en oublier un.
Des tests qui donnent la permission. Pas un taux de couverture, mais une suite assez rapide et assez fiable pour qu’un développeur refactore sans demander.
Le jour où une équipe cesse de faire confiance à ses tests, la base de code cesse d’évoluer; elle ne fait plus que grossir
Des dépendances qui pointent vers l’intérieur. Les règles métier ne dépendent de rien qui se livre, se déploie ou change pour ses propres raisons. Frameworks, bases de données et brokers de messages restent en bordure, là où on peut les remplacer sans renégocier le cœur.
Un pipeline de livraison qui dit la vérité en quelques minutes. L’évolution se fait à petits pas; les petits pas exigent un retour rapide et honnête. Un pipeline qui prend une heure, ou qui est rouge si souvent que personne ne le regarde, impose de grands pas, et les grands pas sont là où les systèmes se figent.
Des décisions écrites là où se trouve le code. Une courte note sur la raison d’être d’une chose évite à l’ingénieur suivant de la redécider, ou de la défaire pour des raisons déjà examinées.
Rien dans cette liste n’exige une réécriture
Tout exige de la discipline pendant des années, ce qui explique que si peu de bases de code l’aient, et que celles qui l’ont valent plus que n’importe quel framework.