Lorsque l'on corrige des bogues dans du code existant, on a facilement tendance à se contenter de repérer l'« erreur » dans le code et de modifier celui-ci pour contourner le problème. Mais si la cause profonde du problème réside dans une erreur de conception ou un problème d'algorithme, se contenter d'ajouter un indicateur ou une instruction goto dans le code n'est pas la bonne approche. Non seulement vous avez laissé la cause profonde intacte, mais vous avez également rendu le code plus difficile à comprendre pour le prochain ingénieur logiciel qui devra le décrypter.
Entraînez-vous à vous demander : « Comment aurais-je résolu ce problème si j’avais été le développeur d’origine ? » Observez ensuite la différence entre l’approche « en partant d’une feuille blanche » et celle qui se trouve réellement devant vous. Mais restez pragmatique. Je ne vous suggère certainement pas de réimplémenter une fonction simplement parce que vous et l’auteur avez une approche différente. Considérez cette étape comme une expérience de réflexion. Vous avez un cas de test qui échoue. L’auteur a omis ce cas. Qu’est-ce qui l’a amenée à omettre ce cas ? Si l’auteur avait eu connaissance de ce cas, en quoi son approche aurait-elle été différente ? Ce type de questions est inestimable lorsque l’on examine un code qui fonctionne globalement, mais qui comporte encore quelques bogues.
Dans notre cas, au lieu d’ajouter un paramètre supplémentaire à une fonction interne, d’introduire une nouvelle variable automatique devant être correctement initialisée à trois points d’entrée différents de la procédure principale, et d’ajouter du code pour tester cette nouvelle variable à un moment critique, je me suis rendu compte que nous pouvions corriger l’algorithme en modifiant l’ordre d’exécution des sous-étapes. Une fois cela fait, le besoin de variables supplémentaires et de cas particuliers a disparu. Le code final est en réalité beaucoup plus facile à comprendre que le code d'origine, sans parler de la première tentative de correction. Cela me conforte dans l'idée que nous sommes sur la bonne voie. Le cas de test qui reproduit le problème a prouvé que tant la correction d'origine (trop complexe) que la correction révisée (simplifiée) résolvent le problème. Il ne nous reste plus qu'à nous assurer que nous n'avons rien cassé d'autre.
Étant donné que ce correctif est destiné à une version déjà déployée sur site (c'est-à-dire une version déjà installée chez les clients), nous allons également effectuer trois types de tests de régression approfondis. Deux d'entre eux vérifieront le respect continu de la norme POSIX (le correctif concerne du code qui implémente une fonction POSIX), tandis que le troisième type de test consistera en des tests de régression généraux au niveau du système.
Commencez par corriger l'algorithme. Une fois que l'algorithme est correct, passez au code.