Pourquoi je ne merge jamais sans audit
Tests, couverture, lint, audit post-lot, CI/CD. La séquence complète, et ce qui arrive quand on la saute.
La séquence de validation
- Les tests passent tous, sans exception.
- La couverture reste au-dessus de 80%.
- Le lint est propre.
- Le lot passe par un audit post-livraison.
- Le build CI compile avant merge.
Pourquoi 80% et pas 100%
En dessous de 80%, les zones non testées s'accumulent trop vite. Au-dessus de 90%, on passe du temps a tester des getters et des cas impossibles.
Le seuil n'est pas moral. C'est un compromis de production: assez haut pour rester fiable, assez bas pour ne pas ralentir artificiellement le projet.
Le lint comme première couche de qualité
Le lint attrape les imports morts, les variables inutilisées, les patterns React invalides, les appels impurs en render. C'est la couche de qualité la plus rapide a faire respecter.
Si le lint ne passe pas, je ne considère même pas que le lot est prêt a être discute.
L'audit post-lot, la partie la plus rentable
L'audit se fait avec du recul, souvent le lendemain. Je cherche ce qui a été 'suffisamment bon pour shipper' mais pas encore assez propre pour servir de base au lot suivant.
Sur Grimoire, l'audit du lot 9 a révèle que la logique abonnement dupliquait de la logique wallet. Corrige avant le lot 10. Sans audit, cette dette aurait contamine plusieurs blocs.
Ce qui arrive quand on saute ces etapes
La dette technique n'est pas linéaire. Un lot non valide ne coute pas un lot de retard: il renchérit tous les lots qui suivent.
La discipline n'est pas agreable au quotidien. Mais c'est ce qui fait que le lot 14 peut rester aussi propre que le lot 1.