Est-il possible d'atteindre l'état zéro bug absolu pour les logiciels à grande échelle?
Je parle de 20 à 30 millions de lignes de code, des logiciels à l'échelle et à la complexité d'Autodesk Maya par exemple.
Si vous gelez le développement aussi longtemps qu'il le faut, pouvez-vous réellement corriger tous les bogues jusqu'à ce qu'il n'y ait tout simplement pas un seul bogue, si une telle chose pouvait être vérifiée par les ordinateurs? Quels sont les arguments pour et contre l'existence d'un système sans bug?
Parce qu'il y a une certaine idée que chaque correction que vous faites crée plus de bugs, mais je ne pense pas que ce soit vrai.
Par bogues, je voulais dire des fautes de frappe les plus simples dans l'interface utilisateur, à des bogues préventifs plus graves qui n'ont aucune solution de contournement. Par exemple, une fonction de script particulière calcule incorrectement les normales. Même s'il existe des solutions de contournement, le problème doit toujours être résolu. Vous pouvez donc dire que vous pouvez faire cette chose en particulier manuellement au lieu d'utiliser la fonction fournie, mais cette fonction doit encore être corrigée.
Comme Mikey l'a mentionné, l'écriture de code sans mémoire n'est pas l'objectif. Si c'est ce que vous visez, alors j'ai de très mauvaises nouvelles pour vous.
Le point clé est que vous sous-estimez largement la complexité des logiciels.
Tout d'abord - Vous ignorez la vue d'ensemble du fonctionnement de votre programme. Il ne fonctionne pas isolément sur un système parfait. Même le plus basique des programmes "Hello World" s'exécute sur un système d'exploitation, et donc, même le plus simple des programmes est sensible aux bogues qui peuvent exister dans le système d'exploitation.
L'existence de bibliothèques rend cela plus complexe. Alors que les systèmes d'exploitation ont tendance à être assez stables, les bibliothèques sont un sac mixte en matière de stabilité. Certains sont merveilleux. Autres ... pas tant que ça ... Si vous voulez que votre code soit 100% sans bogue, alors vous devrez également vous assurer que chaque bibliothèque que vous utilisez est complètement sans bogue, et bien souvent cela n'est tout simplement pas possible car vous n'avez peut-être pas le code source.
Ensuite, il y a des sujets de réflexion. La plupart des programmes à grande échelle utilisent des threads partout. Nous essayons d'être prudents et d'écrire des threads de telle manière que les conditions de concurrence et les blocages ne se produisent pas, mais il n'est tout simplement pas possible de tester toutes les combinaisons possibles de code. Afin de tester cela efficacement, vous devez examiner chaque ordre possible de commandes passant par le CPU. Je n'ai pas fait le calcul sur celui-ci, mais je soupçonne que l'énumération de tous les jeux d'échecs possibles serait plus facile.
Les choses vont de difficile à impossible quand on regarde la machine elle-même. Les CPU ne sont pas parfaits. RAM n'est pas parfait. Les disques durs ne sont pas parfaits. Aucun des composants d'une machine n'est conçu pour être parfait - ils sont conçus pour être "assez bons". Même un programme parfait finit par échouer en raison d'un hoquet de la machine. Vous ne pouvez rien faire pour l'arrêter.
Bottom line: Pouvez-vous écrire "Logiciel sans bug"?
NON
Quiconque vous dit le contraire n'a aucune idée.
Essayez simplement d'écrire un logiciel facile à comprendre et à gérer. Une fois que vous avez fait cela, vous pouvez l'appeler un jour.
EDIT: Certaines personnes ont commenté un excellent point que j'avais complètement ignoré: le compilateur.
Sauf si vous écrivez dans Assembly, il est tout à fait possible que le compilateur gâche votre code (même si vous prouvez que votre code est "parfait").
Une liste de bogues dans GCC, l'un des compilateurs les plus couramment utilisés: http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%2B%2B&resolution=--- =
Mathématiquement, il POURRAIT être possible d'écrire un logiciel "sans bu" d'une telle complexité, selon la façon dont vous définissez "bug". Le prouver [[# # ~] pourrait [~ # ~] être également mathématiquement possible, en concevant un système de test qui exercerait chaque ligne de code de toutes les manières possibles - tous les cas d'utilisation possibles. Mais je ne suis pas sûr - si vous avez affaire à un système qui fait des calculs complexes, vous pouvez rencontrer un `` problème d'infini '' ...
Concrètement, dans un système de la taille et de la portée dont vous parlez, c'est IMPOSSIBLE . Cela pourrait prendre 1000 ans pour écrire un tel système "sans bogue", et pour écrire un système pour prouver qu'il prendrait beaucoup plus de temps: il faudrait trouver tous les cas d'utilisation possibles et écrire un système qui testerait chacun un - et je ne crois pas qu'il y ait moyen de déterminer que vous avez réellement couvert tous les cas d'utilisation dans un système de la taille et de la portée dont vous parlez dans quelque chose qui ressemble à un laps de temps raisonnable.
OMI, votre question est un peu mal dirigée: notre objectif en tant que développeurs n'est pas d'écrire des logiciels "sans bugless". Notre objectif est d'écrire TILISABLE, FLEXIBLE, FACILEMENT MAINTENABLE logiciel.
tilisable: Le système répond aux exigences essentielles pour lesquelles il a été conçu. Il peut y avoir des bogues - mais ils seront dans les "cas marginaux" - des valeurs aberrantes ou des ennuis, pas des bogues qui compromettent les fondamentaux du système - robustes.
Maintenable: Les bogues peuvent être facilement isolés et corrigés et NE PAS créer de nouveaux bogues.
Flexible: Votre système est facile à changer et à étendre sans refonte et temps d'arrêt importants: la plupart des changements nécessitent simplement d'ajouter une nouvelle classe ou module qui s'intègre avec vos modèles et votre cadre déjà bien conçus.
Bonnes pratiques de conception, bonnes pratiques de contrôle, bon travail d'équipe, développeurs consciencieux - telle est la formule pour BON LOGICIEL . (pas - PARFAIT - mais BON )
Selon cet article, le logiciel embarqué pour la navette spatiale était très proche - les trois dernières versions du programme 420 000 lignes avaient chacune une seule erreur. Le logiciel était géré par un groupe de 260 hommes et femmes. Un grand nombre de ces personnes étaient des vérificateurs, dont le seul but était de trouver des erreurs.
La mise à niveau du logiciel pour permettre à la navette de naviguer avec les satellites de positionnement global n'a impacté que 1,5% du programme, soit 6 366 lignes de code. Les spécifications de ce changement comportaient 2 500 pages. Les spécifications de l'ensemble du programme comprenaient 30 volumes et comportaient 40 000 pages, soit une moyenne de dix lignes de code par page de spécification.
Le budget n'était pas un problème - à 35 millions de dollars par an, ils pouvaient se permettre de bien faire les choses.
Essentiellement, non, mais vous devriez quand même faire de votre mieux. Je vais vous expliquer pourquoi (ou passez simplement à la conclusion si vous n'avez pas assez de patience)
Considérons un problème aussi trivial que l'implémentation de la recherche binaire. Une implémentation très populaire avait un bug qui n'a pas été détectée pendant environ deux décennies. Si vingt lignes mettent vingt ans à être exemptes de bogues pour être largement utilisées et même censées être correctes, pouvons-nous vraiment nous attendre à ce qu'un énorme programme soit exempt de bogues?
De combien de bogues peut-on s'attendre d'un énorme programme de toute façon? Un nombre que j'ai trouvé était "10 défauts pour 1000 lignes" (Code Complete 2e édition, page 517 - simplement utilisé un exemple, sans citer de données) Cela nous donne environ 200 000 à 300 000 bogues dans votre logiciel. Heureusement, nous avons des moyens d'améliorer la qualité du programme. Les tests unitaires, les révisions 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, puisque le logiciel est largement utilisé (et donc largement testé), des bogues vont être trouvés. Nous obtiendrons donc progressivement moins de bugs. Cependant, moins de bogues signifient également que les autres sont plus difficiles à trouver - alors ne vous attendez pas à une courbe linéaire dans la correction des bogues. Les derniers bogues seront vraiment difficiles à trouver et pourraient échapper à la détection pendant plusieurs années (en supposant qu'ils soient jamais trouvés).
Vous semblez également supposer à tort que si le logiciel ne change pas, aucun nouveau bogue n'apparaîtra. Si le logiciel dépend de bibliothèques tierces, de nouvelles versions peuvent casser certaines fonctionnalités - 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 casser une application qui fonctionnait auparavant parfaitement (voir Windows Vista pour un exemple populaire). Considérez également les bogues du compilateur, etc.
Il est difficile de savoir si les outils à l'épreuve du code peuvent vraiment résoudre le problème des logiciels de bogue. Il n'est certainement pas possible de résoudre le problème d'arrêt pour n'importe quel programme, mais il pourrait être possible de prouver qu'un programme se comporte comme spécifié ... Mais alors quoi? Peut-être que le programme de preuve a un bogue. Peut-être que la spécification elle-même a un bug.
Il est donc clair que nous pouvons réduire considérablement le nombre de bogues, mais il est très peu probable que nous arrivions à zéro.
Parce qu'il y a une certaine notion que chaque correction que vous faites crée plus de bugs, mais je ne pense pas que ce soit vrai.
(pas d'italique dans l'original)
Vous avez raison. Cette affirmation est fausse. Voici un exemple:
int main() {
int x[10];
x[10] = 8; //Buffer overflow here
return 0;
}
Maintenant, corrigeons ce bogue:
int main() {
int x[11];
x[10] = 8; //No buffer overflow here
return 0;
}
Voir? Nous avons corrigé un bogue 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 de moins, donc c'est probablement mieux qu'il ne l'était (en supposant que le nouveau bogue n'est pas 10 000 fois pire que les précédents).
En outre, la correction d'un bogue peut exposer de nouveaux. Mais ces bugs peuvent également être corrigés. Si vous faites les choses correctement, le logiciel sera finalement dans un meilleur état qu'au départ.
J'étais vieux par quelques programmeurs de haut niveau qu'il vaut mieux 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 pour 10 bogues graves 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 que vous corrigez, moins de bugs vous reviendront à l'avenir
Moins vous corrigez de bogues, plus il y aura de bogues dans votre logiciel, ennuyant vos utilisateurs. En effet, ils "ne vous reviendront pas dans le futur". Ils ne reviendront pas parce qu'ils ne sont jamais partis en premier lieu. La notion de "retour" est liée aux régressions. Encore une fois, il est possible de réduire le risque de régression.
Certains bogues ne peuvent pas être corrigés car ils sont devenus si largement utilisés que les gens ont commencé à dépendre d'eux et la correction du bogue interromprait le programme pour ces utilisateurs. Ça arrive. Cependant, peuvent-ils vraiment être considérés comme des bogues dans ce cas?
La mentalité "corriger un bogue, faire un bogue" pourrait être liée à Ce monstre horrible - un code tellement illisible et impossible à entretenir que le simple fait de le toucher crée des bogues. Si vous avez un monstre dans votre base de code, vous devrez peut-être d'abord le désunifier avant de faire quoi que ce soit.
Enfin, si vous êtes un mauvais programmeur, il y a le risque que quoi que ce soit vous tactile crée de nouveaux bugs. Cela rendrait évidemment les programmeurs seniors 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 est meilleure.
Conclusion:
- Un logiciel qui continue à recevoir des tonnes de nouvelles fonctionnalités mais aucune correction de bogue ne sera inévitablement nul.
- Un logiciel qui obtient 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 de bugs ont (en moyenne) moins de bugs que ceux qui s'en moquent.
- Il n'est pas raisonnable de s'attendre à ce qu'un programme devienne finalement sans bogue.
- Les programmeurs seniors ne sont pas nécessairement compétents.
- Corrigez vos bugs.
- Adoptez des méthodologies qui améliorent la qualité de votre logiciel.
Les raisons de pas l'écriture de programmes sans bogue sont principalement économiques.
Il existe des méthodes mathématiques pour prouver l'exactitude d'un programme. Dans un cours d'informatique de haute qualité, ils seront mentionnés. Il existe des langages de programmation inventés spécialement à cet effet. En théorie, une programmation sans bugs est possible.
Oui, il y a le matériel imparfait qui peut parfois changer une valeur de bit car un neutrino tiré d'une supernova lointaine il y a des millions d'années vient de frapper votre processeur au bon endroit. D'accord, chaque théorie a ses hypothèses et ses abstractions. Mais en supposant que le processeur fonctionne comme annoncé, il existe des outils matmématiques pour s'assurer que le programme fonctionne correctement également.
Certaines réponses très votées dans ce sujet sont trompeuses. Par exemple, le théorème d'incomplétude de Gödel et le problème d'arrêt impliquent seulement que vous ne pouvez pas avoir par exemple un outil automatisé qui déciderait de l'exactitude ou de l'inexactitude de tout programme . Mais nous ne voulons pas décider de l'exactitude de tout programme , nous voulons seulement une preuve d'exactitude de un programme spécifique .
(Analogiquement, juste parce que vous ne pouvez pas écrire un programme pour déterminer automatiquement la vérité de n'importe quel théorème mathématique, cela ne signifie pas que vous ne pouvez pas prouver un théorème mathématique spécifique .)
Le problème est plutôt le suivant:
Bien qu'il soit théoriquement possible d'écrire un programme sans bug, cela serait très cher. Écrire un code avec une preuve de son exactitude est plus compliqué que de simplement jeter quelque chose contre un mur pour voir s'il colle. Même si "voir si ça colle" se fait par des tests unitaires; et de nombreux programmeurs ne prennent même pas la peine de le faire. La plupart des programmeurs ne sauraient même pas comment faire cela, ce qui signifie qu'en tant qu'entreprise, vous devrez en embaucher plus chers.
Compte tenu de tous les coûts, un client typique est plus satisfait d'un logiciel bon marché qui fonctionne bien 99% du temps (et 99,9% du temps après l'installation de mises à jour supplémentaires) que d'avoir peut-être mille fois plus cher un logiciel qui fonctionne bien 100% des le temps. De plus, le client souhaite disposer de ce logiciel maintenant , et non dans dix ou vingt ans.
Par conséquent, les gens produisent sciemment un logiciel qui a une certaine chance de bogues, essayant de trouver la combinaison optimale où les bogues ne sont pas trop fréquents et pas trop graves, et la production est assez rapide et assez bon marché. La combinaison qui génère le plus de bénéfices dans la vie réelle. (Parfois, cela signifie même de publier un logiciel plein de bogues avant que vos concurrents ne publient quoi que ce soit, et de ne publier une version 2.0 plus décente que lorsque vos concurrents sont prêts à publier leur première version décente.)
Si vous gelez le développement aussi longtemps qu'il le faut, pouvez-vous réellement corriger tous les bogues jusqu'à ce qu'il n'y ait tout simplement pas un seul bogue, si une telle chose pouvait être vérifiée par les ordinateurs?
Mathématiquement parlant, vous pourriez. Sur le plan économique, pourquoi quelqu'un ferait-il cela? Cela signifierait peut-être passer vingt ans et quelques millions de dollars. Pendant ce temps, les clients voudraient de nouvelles fonctionnalités et vos applications figées ne pourraient pas les fournir. Donc, au moment où votre version parfaite est prête, le marché est déjà pris par vos concurrents.
Le raisonnement économique est OK. Nous vivons dans un monde où l'argent et le temps comptent. Mais juste parce que nous ne faisons rien pour des raisons économiques, nous ne devrions pas dire des bêtises sur la façon dont cela ne peut pas être fait, même en théorie. Qui sait ... peut-être que dans quelques années, nous aurons de nouveaux langages de programmation et de nouveaux outils qui pourraient faciliter la vérification de l'exactitude .
Non.
David Hilbert a proposé son deuxième problème de mathématiques en 1900 qui demandait essentiellement au monde de prouver que l'arithmétique fonctionnait comme prévu. Il a ensuite proposé " le Entscheidungsproblem ", qui a demandé quelque chose de similaire en termes logiques. Kurt_Gödel " premier théorème d'incomplétude " a prouvé en 1931 qu'aucune théorie de l'arithmétique élémentaire ne pouvait être à la fois cohérente et complète. Alan Turing représentation du problème Entscheidungsproblem comme " le problème d'arrêt " a placé le problème directement au cœur de cette question, où il a prouvé qu'il est impossible de prouver si un programme exécuter à la fin ou non. Étant donné que undeciability, il est également impossible de prouver si un programme a des bogues ou non.
Rien de tout cela ne libère les programmeurs pratiquants parmi nous de ne rechercher aucun bogue. Cela signifie simplement que nous ne pouvons pas réussir en général.
Errare humanum est
Même si vous écrivez du code avec un langage formel, comme méthode B , que vous pouvez utiliser pour prouver mathématiquement que les exigences sont remplies,
Même si vous utilisez un langage de spécification formel,
Il y a toujours une étape humaine consistant à extraire les besoins de l'utilisateur d'un ou plusieurs cerveaux vers un ordinateur.
Cette étape humaine est sujette aux erreurs et le ver est dans la pomme.
Une bonne partie des "bogues" que j'ai rencontrés pourrait être plus correctement décrite comme des décalages entre la conception du système et les attentes des clients.
Maintenant, que nous appelions ces bogues ou non est académique, mais le fait demeure qu'une bonne partie du travail de maintenance résulte de la communication imparfaite et des attentes changeantes des clients.
Même si un système est techniquement, prouvablement "correct" dans le sens de répondre à une spécification (même si cela est improbable pour un logiciel commercial du monde réel), vous aurez toujours le problème de faire correspondre la fonction du logiciel à celle de votre client. attentes changeantes et mal définies.
En bref:
Non.
Si vous avez une spécification suffisamment stricte et restreinte, vous pourrez peut-être prouver un programme sans bogue, mais uniquement sur la base d'hypothèses non prouvables sur le bon fonctionnement de tout le reste du système. Cela laisse pour acquis qu'il n'y a aucun moyen de prouver que les spécifications seraient considérées comme correctes par la personne qui a posé le problème d'origine ou par la personne qui utilisait le service.
J'ai trouvé la section de Jim Shore No Bugs une lecture très utile sur ce sujet. La forme courte: il n'est pas possible de se développer sans produire de bugs - mais nous pouvons travailler de manière à les détecter le plus tôt possible.
Lors de la production du code lui-même. Par exemple, en écrivant et en exécutant fréquemment des tests unitaires pendant le développement, nous nous assurons constamment que le code fait ce qu'il est censé faire. En outre, il est utile de réécrire en permanence le code existant de telle manière qu'il exprime le plus clairement le comportement du système prévu.
Dans votre cas, cependant, vous parlez d'une base de code déjà existante avec des millions de lignes de code. Si vous voulez obtenir un tel bogue système gratuit, vous devez d'abord savoir ce qui est "un bogue" pour ce système. Vous pouvez écrire des suites de tests post-hoc assurant la fonctionnalité du système (si ce n'est déjà fait). La toile de ces tests peut servir de définition approximative du comportement correct du système. Mais plus vous avez de code, plus l'effort est impliqué dans de tels exercices. Par conséquent, la plupart des entreprises font un compromis: elles vivent avec l'imparfait, en travaillant avec les listes de bogues et la maintenance pour éliminer les bogues les plus ennuyeux du système.
À propos de la vérification par partie informatique.
Il existe deux façons de vérifier un programme à l'aide d'un ordinateur. L'un teste, l'autre utilise un système de preuve.
Dès qu'un test exhaustif n'est pas possible, le test devient incapable de montrer qu'un programme n'a pas de bugs, juste qu'il en a. (Et vous avez le problème de montrer que vos tests eux-mêmes ne testent pas la présence de bogues).
Pour utiliser un système de preuve, vous partez d'exigences formelles (et elles peuvent elles-mêmes avoir un bogue, j'espère que le langage utilisé pour les exigences sera plus approprié pour vous convaincre qu'il n'y a pas de bogue là-bas qu'avec un langage de programmation) et construisez/prouvez avec l'aide de systèmes de preuve que le programme est exempt de bogues (et il y a la question des bogues dans les systèmes de preuve, mais ils se sont avérés corrects). L'état actuel de la technique est un compilateur pour un sous-ensemble C (et le sous-ensemble n'est pas académique, "CompCert prend en charge tous les MISRA-C 2004 sous-ensemble de C, ainsi que de nombreuses fonctionnalités exclues par MISRA ").
Non, car l'environnement informatique et logiciel sur lequel l'application s'exécute continuera de changer même lorsque le code est figé. Le système d'exploitation continue d'évoluer avec les correctifs et les correctifs, ainsi que les périphériques et les pilotes. Juste au moment où vous pensez n'avoir atteint aucun point de bogue connu, AMD ou nVidia publiera une mise à jour du pilote vidéo qui influe sur la façon dont vous interagissez avec le sous-système vidéo. Maintenant, votre application présente des défauts visuels (comme le clignotement, le scintillement ou la réduction de la fréquence d'images) pour les clients qui ont une certaine carte vidéo ou configuration (SLI? LOL).
Mis à part le matériel et le système d'exploitation, il existe également un certain nombre de produits middleware sous les applications les plus importantes qui évolueront également hors de votre contrôle, et tout comme vous obtenez votre code à un état de défaut zéro, les couches sous-jacentes sont finalisées.
La technologie évolue, ainsi que l'entreprise qui exploite la technologie, et l'idée de "libérer" le code n'est ni possible ni faisable. L'entreprise demandant un nouvel ensemble de fonctionnalités ne répondra pas bien à "nous avons le code verrouillé pendant que nous poursuivons tous les bogues connus et personne ne signale un défaut logiciel valide dans X mois". Même si l'entreprise achète cette ligne, après X mois, elle demandera comment les nouvelles fonctionnalités se présentent, et la réponse ne peut pas être "nous avons décidé de prolonger le gel car Oracle vient de publier un correctif et nous devons prendre X mois supplémentaires pour certifier que ".
Non, à un moment donné, l'entreprise recherchera une équipe de développement plus flexible qui répondra à la nécessité d'avancer à la vitesse de la technologie. C'est le problème fondamental auquel sont confrontées les équipes de développement modernes.
Oui mais tu ne le sauras jamais avec certitude. Plus vous regardez dur, plus vous en trouverez. Plus le système est utilisé et plus les cas Edge sont utilisés, plus vous trouverez un autre décalage avec l'intention ou les spécifications d'origine. Cela implique qu'un bogue lui-même n'est pas une chose exacte et dépendra souvent de l'interprétation, de la gravité de l'individu qui évalue une anomalie perçue.
C'est une chose floue. Peu de systèmes sont spécifiés jusqu'au dernier bit. Si un système fonctionne bien et que les utilisateurs ne se plaignent pas (ils ne sont pas buggés par quoi que ce soit) et qu'ils y sont totalement adaptés, vous pouvez aussi l'appeler sans bug.