Il n'y a pas de réponse absolue, et c'est justement l'idée. — vous adaptez la rigueur aux et à la du code. Un prototype jetable et un système de paiement core méritent des standards très différents. Le rôle du lead est de prendre cet arbitrage , plutôt que de le laisser se faire par accident.
Poser trois questions avant de prendre un raccourci:
// TODO, une note dans le RFC). Vous savez exactement ce que vous avez échangé et pourquoi.Maintenir le core propre même sous pression: des frontières bien nommées, des chemins critiques testés. Reléguez le chaos aux marges où c'est bon marché de l'éliminer.
Quand une deadline est serrée, le geste honnête est de renégocier le périmètre ou le temps avec les stakeholders — pas de livrer silencieusement quelque chose de fragile. "On peut tenir la date avec les features A et B, mais C décale d'une semaine" est une vraie conversation. Livrer silencieusement du code fragile dépense la vélocité future de l'équipe sans que personne n'ait accepté de le faire.
Les équipes qui optimisent toujours pour la vitesse se noient dans la dette; les équipes qui gold-plate toujours manquent les marchés. La valeur du lead est le jugement — calibrer la rigueur au contexte et rendre l'arbitrage visible et approprié, de sorte que le raccourci d'aujourd'hui est un choix que l'équipe peut rembourser, pas une surprise qu'elle hérited'une autre manière.