Cela sera sur notre chaine Twitch.

TLDR:
On veut des équipes de dev plus efficaces, autonomes et rapides. Mais l'architecture et la santé de nos codebases peuvent en prendre un coup ! Et si on reprenait le contrôle en faisant ressortir les bons insights ? Au-delà d'une analyse statique, git nous offre une perspective temporelle précieuse.

Description :
Ça y est, vous y êtes ! Votre organisation va vite grâce à des équipes autonomes et performantes ! Tout le monde fait pour le mieux, et il n'y a pas de barrières !
Dans ce contexte, les problématiques transverses telle que la santé de la codebase ou la bonne architecture du produit sont l'affaire de tous. Et avec un monorepo c'est encore plus facile !

Mais avec l'accroissement de la codebase, du nombre de modules, du nombre de développeurs et d’équipes, il devient difficile de bien raisonner sur ces problématiques. Et très vite ce n'est plus l'affaire de personne, mais l'expérience dev s'en ressent, l'efficacité baisse, le sentiment de dette technique grandit...

Alors évidemment une analyse statique avec Sonar peut aider, mais ne relèvera pas que votre codebase n'est plus alignée avec vos équipes, les grands axes de votre produit, vos bounded contexts.
Des tests d'architecture peuvent aider également, mais ils ne serviront que pour les problèmes déjà identifiés.
Fort heureusement vous avez des communautés de pratiques, des guildes transverses, pour se saisir de ces points et assurer la cohésion à grands coups d'ADR (architecture decision records). Mais le temps disponible est limité, et on navigue parfois à vue !

Bref, il serait bien utile de faire remonter des tendances dans l'évolution de notre codebase, et surtout des alertes quand ces tendances ne vont pas dans la bonne direction. Différents outils plus ou moins performants et plus ou moins coûteux existent pour aider, mais pourquoi ne commencerions-nous pas avec ce que nous avons déjà ?

Ainsi, nous verrons comment utiliser git pour ajouter une dimension temporelle et une dimension d'équipe à nos analyses, et ainsi répondre à des questions diverses telles que :

- Y a-t-il adéquation entre les zones de code manipulées par les équipes et leurs responsabilités ?
- Y a-t-il des zones de friction entre équipes ?
- Quels sont les "points chauds" de la codebase ? Des zones instables ou risquées
- Quels sont les couplages "invisibles" ? Des zones changées de concert ou presque
- Comment suivre facilement un refactoring, la mise en place de nouvelles pratiques, dans le code à travers le temps ?
- Qui connaît telle ou telle zone ?
- Etc.

... et comment transformer tout ça en graphiques, pour une communication la plus claire possible.