Depuis des années, j’essaie de suivre avec rigueur la doctrine suivante dans les projets utilisant le workflow Trunk-Based Development.
- La branche trunk doit toujours être stable et contenir uniquement du code fonctionnel.
- Le code obsolète ou inutilisé doit être supprimé de la branche trunk.
- Aucun code commenté ne doit figurer dans la branche trunk.
- La branche trunk ne contient pas de tests qui échouent.
Pourquoi ?
- Pour éviter qu’un développeur perde du temps à essayer de faire fonctionner quelque chose qui n’est pas en état de marche.
- Pour éviter qu’un développeur refactore du code mort — j’ai observé à nouveau cela, il n’y a pas longtemps 😔. Quand le développeur fini par le découvrir, il est généralement très frustré.
- Pour éviter l’installation et la mise à jour de bibliothèques qui alourdissent inutilement le projet.
- Pour prévenir une perte de confiance dans le projet (voir l’hypothèse de la vitre brisée).
Et si j’ai besoin de ce code plus tard ?
Tout d’abord, je vous réponds “YAGNI” 🙂.
Plus sérieusement, ma réponse est que votre code ne sera pas perdu étant donné qu’il est versionné dans votre repository.
Si le code commenté est en cours de développement, alors je suggère d’extraire ce code en préparation dans une Merge Request et de la merger quand elle sera prête.
Trouvez le bon équilibre
Un morceau de code commenté ou un test qui échouent peut tout à fait rester dans trunk sur une courte période. Dans ce cas, je conseille d’ajouter en commentaire un lien vers l’issue de dette technique qui détaille l’action prévue.