Bug or feature?
Qui s’est déjà prêté sérieusement à l’exercice du refactoring a probablement rencontré ce genre de code :
class Game {
// tout plein de choses qui vous font saigner les yeux
private didPlayerWin(): boolean {
return this.points[this.currentPlayer] != 6;
}
}Il n’y a pas besoin d’être grand clerc pour voir qu’il y a un problème : les joueurs démarrant la partie avec 0 point, chaque joueur est gagnant alors que la partie n’a pas démarré 😳
Petit instant d’hésitation, quand-même : ne serait-ce pas une fonctionnalité « du troisième type » ? Autrement dit : bug or feature?
Ici, le reste du code confirmerait votre intuition qu’il s’agit d’une erreur grossière. Mais dans bien des cas, la question reste en suspens. Peut-être mettrez-vous la main sur une documentation fonctionnelle, et dans ce cas-là, prions pour qu’elle soit à jour et ne contredise pas le code.
Le mieux serait donc de demander à quelqu’un, développeur ou product manager, sauf que tout ce beau monde vogue depuis longtemps vers de nouveaux horizons, tandis que vous restez seul avec vos questions 🥲 La mauvaise nouvelle, c’est qu’il n’y a aucune solution toute faite : vous devrez y aller armé de votre bon sens et d’une solide connaissance métier.
Que faire ensuite dans l’éventualité où le bug est avéré ? Cette question peut paraître surprenante, mais… faut-il le corriger ? En effet, si le bug est en place depuis des années, il y a fort à parier que le monde extérieur ait mis en place ses propres mesures correctrices pour « faire avec ».
Exemple non informatique : imaginons que votre robinet soit monté à l’envers. Quand vous demandez de l’eau froide, c’est de l’eau chaude qui sort, et réciproquement. Vous vous êtes bien brûlé une fois, mais vous n’aviez pas envie de tout démonter alors vous vous êtes adapté : pour obtenir de l’eau froide, vous demandez de l’eau chaude et réciproquement. Facile, après tout : il suffit de le savoir.
Évidemment, si vous m’invitez chez vous et qu’à cette occasion je répare la chose sans rien vous dire, on vous entendra probablement pousser un grand cri la prochaine fois que vous vous laverez les mains.
Autrement dit, si vous corrigez le bug, tous les systèmes tiers qui utilisent votre service vont devoir supprimer les mesures de contournement qu’ils avaient mises en place pour faire avec. Vous devez donc être en mesure de les en informer et de coordonner tout ce beau monde. Dans certains cas c’est faisable (ex : une API utilisée par un seul front), dans d’autres, c’est beaucoup plus compliqué et peut-être inenvisageable (ex : de nombreux clients institutionnels à contacter individuellement pour un système legacy, condamné sur le long terme mais devant évoluer dans le court terme).
Que faire, alors ? En pareille situation, vous pourriez envisager de corriger le bug et de le réintroduire aussitôt au travers d’une fine surcouche. Une pratique qui, bien que paradoxale, permet d’isoler le code dysfonctionnel et de permettre au reste de la codebase d’évoluer librement en assurant à tout instant sa cohérence fonctionnelle.
À défaut de pouvoir traiter le problème, vous vous contentez de le circonscrire.