Lorsque vous corrigez des bogues dans un code existant, il est facile de prendre l'habitude de trouver l'"erreur" dans le code et d'ajuster le code pour éviter l'erreur. Mais si la cause première du problème est une erreur de conception ou un problème avec l'algorithme, alors le simple fait d'ajouter un autre drapeau ou une déclaration "goto" dans le code est la mauvaise approche. Non seulement vous avez laissé la cause première intacte, mais vous avez rendu le code plus difficile à comprendre pour le prochain ingénieur logiciel qui doit le résoudre.
Entraînez-vous à vous demander "comment aurais-je résolu ce problème si j'étais le codeur d'origine ? Ensuite, regardez la différence entre l'approche de la "feuille blanche" et celle qui se trouve en fait devant vous. Mais soyez pragmatique. Je ne suggère certainement pas que vous devriez réimplanter une fonction parce que vous et l'auteur avez une approche différente. Prenez cette étape comme une expérience de réflexion. Vous avez un cas d'essai qui échoue. L'auteur a raté ce cas. Qu'est-ce qui l'a amenée à manquer ce cas ? Si l'auteur avait été au courant de ce cas, en quoi son approche aurait-elle été différente ? Ce type de questions est très utile pour fouiller dans un code qui fonctionne, mais qui présente encore quelques bugs.
Dans notre cas, au lieu d'ajouter un autre paramètre à une fonction interne, et d'ajouter une autre variable automatique qui devait être correctement initialisée à 3 points d'entrée différents de la procédure principale, et d'ajouter du code pour tester cette nouvelle variable à un point critique, j'ai réalisé que nous pouvions réparer l'algorithme en modifiant l'ordre dans lequel les sous-étapes étaient exécutées. Une fois que nous avons fait cela, le besoin de variables supplémentaires et de cas spéciaux a disparu. Le code final est en fait beaucoup plus facile à comprendre que le code original, sans parler de la première tentative de réparation. Cela me donne confiance dans le fait que nous sommes sur la bonne voie. Le cas de test qui reproduit le problème a prouvé que la réparation originale (trop complexe) et la réparation révisée (simplifiée) résolvent toutes deux le problème. Maintenant, nous devons juste nous assurer que nous n'avons rien cassé d'autre.
Comme ce correctif est destiné à être mis en œuvre sur le terrain (c'est-à-dire déjà installé chez les clients), nous effectuerons également trois types de tests de régression intensifs. Deux d'entre eux vérifieront le respect de la norme POSIX (la correction de bogue est dans le code qui implémente une fonction POSIX), et le troisième type de test est un test de régression général au niveau du système.
Fixez d'abord l'algorithme. Une fois que l'algorithme est correct, il faut s'occuper du code.