Essentiellement, non, mais vous devriez quand même faire de votre mieux. Je vais expliquer pourquoi (ou sauter simplement à la conclusion si vous n'avez pas assez de patience)
Considérez un problème aussi trivial que l'implémentation de la recherche binaire. Une implémentation très populaire avait un bogue qui n’a pas été détecté pendant environ deux décennies. Si vingt lignes mettent vingt ans à être largement utilisées et même supposées être correctes, peut-on vraiment s'attendre à ce qu'un énorme programme soit exempt de bogues?
Combien de bogues pouvons-nous espérer avoir avec un programme énorme? Un chiffre que j'ai trouvé était "10 défauts par 1000 lignes" (Code Complete 2nd edition, page 517 - à titre d'exemple, sans citer de données). Cela nous donne entre 200 000 et 300 000 bogues dans votre logiciel. Heureusement, nous avons des moyens d'améliorer la qualité du programme. Les tests unitaires, les revues de code et les tests manuels ordinaires sont connus pour réduire le nombre de bogues. Pourtant, le nombre sera toujours élevé.
Si nous pouvions résoudre 95% de tous les bugs, ce serait incroyable. Et pourtant, nous aurions encore 10 000 à 15 000 bogues dans le logiciel.
Heureusement, étant donné que le logiciel est largement utilisé (et donc largement testé), des bogues vont être trouvés. Donc, nous aurons progressivement moins de bugs. Cependant, moins de bogues signifie également que les derniers sont plus difficiles à trouver - ne vous attendez donc pas à une courbe linéaire pour la correction des bogues. Les derniers bugs vraiment difficile à trouver et pourrait échapper à la détection pendant plusieurs années ( en supposant qu'ils sont toujours trouvés).
Vous semblez également présumer à tort que si le logiciel ne change pas, aucun nouveau bogue n'apparaîtra. Si le logiciel dépend de bibliothèques tierces, les nouvelles versions risquent de casser certaines fonctionnalités - en introduisant de nouveaux bogues même si le code de l'application est toujours le même. Les nouveaux systèmes d'exploitation peuvent également endommager une application qui fonctionnait auparavant parfaitement (voir Windows Vista pour un exemple classique). Considérez également les bogues du compilateur, etc.
Il est difficile de savoir si des outils à l'épreuve du code peuvent vraiment résoudre le problème des logiciels buggy. Il n’est certes pas possible de résoudre le problème d’arrêt de tout programme, mais il serait peut-être possible de prouver qu’un programme se comporte comme prévu ... Mais alors quoi? Peut-être que le programme de preuve a un bug. Peut-être que la spécification elle-même a un bogue.
Nous pouvons donc réduire considérablement le nombre de bugs, mais il est très peu probable que nous arrivions à zéro.
Parce qu'il y a une notion que chaque correctif que vous apportez crée plus de bugs, mais je ne pense pas que ce soit le cas.
(emphase ajoutée)
Vous avez raison. Cette déclaration est fausse. Voici un exemple:
int main() {
int x[10];
x[10] = 8; //Buffer overflow here
return 0;
}
Maintenant, corrigeons ce bug:
int main() {
int x[11];
x[10] = 8; //No buffer overflow here
return 0;
}
Voir? Nous avons corrigé un bug et n'en avons introduit aucun nouveau.
Cependant, il est certainement exact que chaque fois que vous corrigez un bogue, vous risquez d'en créer un nouveau, bien que ce risque puisse être atténué (par exemple avec des tests unitaires).
Disons que pour chaque 100 bugs que je corrige, j'en introduis accidentellement un nouveau. Donc, si je corrige 10 000 bogues, j'introduis 100 nouveaux bogues. Et si je corrige ces nouveaux bogues, j'introduis un bogue. Mais alors quoi? Le programme a maintenant 9 999 bogues en moins, il est donc probablement meilleur qu’il ne l’était (en supposant que le nouveau bogue ne soit pas 10 000 fois pire que les précédents).
De plus, la correction d'un bogue peut en exposer de nouveaux. Mais ces bugs peuvent également être corrigés. Si vous faites les choses correctement, le logiciel finira par être dans un meilleur état qu’il a commencé.
Quelques programmeurs de haut niveau m'avaient dit qu'il était préférable de ne pas corriger beaucoup de bugs à cause de la notion que j'ai mentionnée dans l'OP.
Ce comportement est négligent. S'il y a un bug et que vous pouvez le corriger. Fais le. Bien sûr, vous devriez faire de votre mieux pour éviter d'en ajouter de nouveaux, mais si j'introduis un petit bogue sur 10 que je corrige, ce n'est pas une raison valable pour arrêter de corriger les bogues. En fait, c'est une bonne raison de continuer à corriger les bugs .
Donc moins de bugs corrigés, moins de bugs vous reviendront dans le futur
Moins vous corrigez de bugs, plus il restera de bogues dans votre logiciel, ce qui agacera vos utilisateurs. En effet, ils ne "reviendront pas à vous dans le futur". Ils ne reviendront pas car ils ne sont jamais partis en premier lieu. La notion de "retour" est liée aux régressions. Là encore, il est possible de réduire le risque de régression.
Certains bugs ne peuvent pas être corrigés car ils sont devenus tellement utilisés que les gens ont commencé à en dépendre, et la résolution du bogue ferait perdre le programme à ces utilisateurs. Ça arrive. Cependant, peuvent-ils vraiment être considérés comme des bugs dans ce cas?
La mentalité «réparer un bogue, créer un bogue» pourrait être liée à That Horrible Monster - un code tellement illisible et tellement incalculable qu'il suffit de le toucher pour créer un bogue. Si vous avez un monstre dans votre base de code, vous devrez peut-être d'abord le dé-monstreifier avant de faire quoi que ce soit.
Enfin, si vous êtes un mauvais programmeur, il y a un risque que tout ce que vous touchez crée de nouveaux bogues. Cela rendrait évidemment les programmeurs expérimentés nerveux. Cependant, en disant "Ne faites rien. Ne touchez à rien. Ne respirez même pas." n’est probablement pas la bonne façon de créer un environnement de travail sain. L'éducation c'est mieux.
Conclusion:
- Un logiciel qui ne cesse d’obtenir des tonnes de nouvelles fonctionnalités, mais aucune solution de bogue ne sera inévitablement nul.
- Un logiciel qui reçoit un nombre modéré de nouvelles fonctionnalités mais qui corrige ses bogues a de meilleures chances d'être utilisable.
- Ceux qui essaient d'avoir peu d'insectes ont (en moyenne) moins d'insectes que ceux qui s'en moquent.
- Il n'est pas raisonnable de s'attendre à ce qu'un programme finisse par devenir exempt de bogues.
- Les programmeurs expérimentés ne sont pas nécessairement compétents.
- Corrigez vos bugs.
- Adoptez des méthodologies qui améliorent la qualité de vos logiciels.