Le vrai coût d'une compilation lente
Une compilation qui prend trois minutes au lieu de trente secondes ne coûte pas seulement du temps. Elle remodèle discrètement la façon dont toute votre équipe travaille, et rarement pour le mieux.
Personne ne planifie de réunion sur les temps de compilation. Ils grimpent une dépendance à la fois jusqu'à ce qu'une reconstruction complète soit assez longue pour justifier un coup d'œil à votre téléphone. Cette pause semble anodine. Elle ne l'est pas.
Le contexte est ce que vous perdez réellement
Quand une compilation prend trente secondes, vous restez dans le problème. Quand elle en prend trois minutes, vous en sortez. Vous changez d'onglet, lisez un message, suivez un lien, et le temps que la compilation se termine, vous devez reconstruire le modèle mental que vous venez d'abandonner. Le coût en temps réel est de quelques minutes. Le vrai coût, c'est le rechargement.
Les compilations lentes changent les comportements
Les équipes s'adaptent à un retour lent de manières qui rendent le code pire. Elles regroupent des changements non testés parce qu'exécuter la boucle coûte cher. Elles renoncent à la petite refactorisation parce qu'elle ne vaut pas une nouvelle attente. Elles cessent d'écrire l'expérience rapide qui aurait répondu à une question dans le code plutôt que dans un débat.
La vitesse de votre boucle de rétroaction détermine la taille du plus petit changement que quiconque est prêt à faire.
Traitez-le comme une métrique de premier plan
Mesurez le temps de compilation et de test comme vous mesurez la disponibilité. Mettez-le sur un tableau de bord. Fixez un budget et défendez-le en revue. Quand un changement pousse la compilation au-delà du budget, c'est un coût réel à peser, pas une erreur d'arrondi à ignorer.
Des compilations rapides ne sont pas un luxe réservé aux grandes équipes. Elles sont le socle qui permet à une petite équipe de continuer à avancer comme une petite équipe.