Quel niveau de qualité attendez-vous de votre équipe, et comment le faites-vous respecter ?

Fixez le niveau selon le risque plutôt que par une règle uniforme. Définissez ce qui doit être vrai avant qu'un code parte (des tests qui attrapent les modes de défaillance réalistes, une revue par quelqu'un capable de vraiment contester, de l'instrumentation sur le nouveau chemin, un chemin de retour documenté) et automatisez tout ça autant que possible dans le pipeline. Faites respecter par les valeurs par défaut et l'automatisation plutôt qu'en harcelant en revue de code.

Je le fixe selon le rayon d'explosion. Un changement sur le chemin de paiement et un changement sur une page marketing ne méritent pas le même cérémonial, et appliquer un standard unique aux deux veut dire soit tout ralentir, soit se brûler là où ça compte. Pour tout ce qui compte, ma liste c'est des tests qui attraperaient vraiment la défaillance réaliste plutôt que du théâtre de pourcentage de couverture, un relecteur qui connaît assez le domaine pour être en désaccord, de l'instrumentation sur le nouveau chemin pour qu'on puisse le surveiller en production, et un chemin de retour documenté. Ensuite je pousse tout ça dans le pipeline autant que je peux, parce que les standards qui reposent sur la mémoire humaine en revue se dégradent en un mois environ. Lint, portes de test, vérifications de migration, une note de rollback obligatoire dans le gabarit. Quand quelqu'un de senior le contourne, je traite ça comme une conversation sur le standard plutôt que sur la personne, parce qu'en général elle a une vraie raison et c'est le standard qui a tort. Si ça se reproduit sans raison, c'est une conversation de performance, pas de processus.