Est-il possible d'atteindre l'état de zéro absolu avec un logiciel à grande échelle?


71

Je parle de 20-30 + millions de lignes de code, de logiciels à l’échelle et à la complexité d’Autodesk Maya par exemple.

Si vous bloquez le développement aussi longtemps que nécessaire, pouvez-vous réellement corriger tous les bogues jusqu'à ce qu'il n'y ait plus aucun bogue, si une telle chose pouvait être vérifiée par des ordinateurs? Quels sont les arguments pour et contre l'existence d'un système sans bug?

Parce qu'il y a une notion que chaque correction que vous apportez crée plus de bugs, mais je ne pense pas que ce soit le cas.

Par bogues, je voulais dire des fautes de frappe les plus simples de l'interface utilisateur aux bogues préventifs plus graves sans solution de contournement. Par exemple, une fonction de script particulière ne calcule pas les normales de manière incorrecte. De plus, même en présence de solutions de contournement, le problème doit toujours être résolu. Vous pouvez donc dire que vous pouvez faire cette chose particulière manuellement au lieu d'utiliser la fonction fournie, mais cette fonction doit toujours être corrigée.


11
"Quelques programmeurs de haut niveau l'ont dit" - pour moi, ils ne ressemblent pas aux meilleurs programmeurs. Ils sonnent comme des pirates informatiques. L'une des principales responsabilités d'un programmeur est de comprendre le rôle de son code et son impact sur le système dans son ensemble. C'est pourquoi nous avons le TDD, les modèles de conception, etc. Si cela ne peut pas être fait, le système est une ordure - le processus de développement a été effectué de manière chaotique, aléatoire, indisciplinée et non scientifique.
Vecteur

51
Si vous ne savez pas encore qu'il existe un bogue, s'agit-il encore d'un bogue?
Blrfl

5
@Blrf: Plus important encore, si l'utilisateur final ne connaît pas de bogue, existe-t-il?
mattnz

40
«Il y a deux façons de concevoir un logiciel. Une solution consiste à simplifier les choses de manière évidente. Et l’autre façon de faire est si compliqué qu’il n’y ait aucune lacune évidente. »- CAR Hoare
Andrew Lewis

5
C'est vrai, mais beaucoup de gens ne veulent pas que leurs croyances fondamentales soient remises en question.
Joan Venge

Réponses:


92

Comme Mikey l’a mentionné, l’écriture de code sans bouts n’est pas l’objectif. Si c'est ce que vous visez, j'ai de très mauvaises nouvelles pour vous.

Le point clé est que vous sous-estimez énormément 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 fondamental des programmes "Hello World" fonctionne sur un système d'exploitation. Par conséquent, même le plus simple des programmes est sujet aux bogues pouvant 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 relativement stables, les bibliothèques sont un mélange de stabilité. Certains sont merveilleux. D'autres ... pas tellement ... Si vous voulez que votre code soit 100% exempt de bogues, vous devez également vous assurer que chaque bibliothèque que vous utilisez est totalement exempte de bogues, ce qui n'est souvent pas possible. vous ne pouvez pas avoir le code source.

Ensuite, il y a des sujets à prendre en compte. La plupart des programmes à grande échelle utilisent des threads partout. Nous essayons d'être prudents et d'écrire les threads de manière à éviter les conditions de concurrence et les blocages, mais il n'est tout simplement pas possible de tester toutes les combinaisons de code possibles. Afin de tester cela efficacement, vous devez examiner chaque ordre possible de commandes passant par la CPU. Je n'ai pas fait le calcul sur celui-ci, mais je soupçonne qu'il serait plus facile d'énumérer tous les jeux d'échecs possibles.

Les choses vont de difficile à impossible quand on regarde la machine elle-même. Les processeurs ne sont pas parfaits. La RAM n'est pas parfaite. 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 finira par échouer à cause d'un hoquet de la part 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 à maintenir. 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 oublié: le compilateur.

Sauf si vous écrivez en assembleur, 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 utilisés: http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%2B%2B&resolution=---


8
La réponse est toujours "non", car il y aura toujours des "bugs" où quelque chose fonctionne - mais pas comme un client ou un propriétaire de produit voudrait que cela fonctionne. Certains d'entre nous peuvent appeler ces demandes de fonctionnalités, ou des demandes de changement de comportement ou d'ajout de fonctionnalités - mais pour la personne gênée chaque jour par un "bogue", la chose qui les gêne est un bogue. (C'est une longue façon de dire que certains insectes sont dans l'œil du spectateur.) Le code sans bogue est impossible. Visez un code suffisamment bon pour atteindre le but recherché.
Rapidement maintenant

6
J'irai un peu plus loin: le code peut avoir des défauts latents, par exemple, vous pourriez avoir un code qui ne vérifie pas correctement une entrée. Si, pour une raison quelconque, l'entrée n'est jamais hors de portée, le bogue ne se manifeste jamais. Puis, un jour au cours de la maintenance ou du changement de fonctionnalité, cet élément de code est appelé depuis un autre endroit qui ne l'exerce PAS de temps en temps avec une valeur hors limites. Le virus se manifeste maintenant - mais il était là depuis le début. Vous pouvez avoir des degrés de folie dans tout cela - mais l'élimination de toute possibilité d'injustice est toujours impossible.
Rapidement maintenant

11
@ JohnR.Strohm Je ne vois pas pourquoi vous pensez que le programme 'modulateur de flux de messages', un programme avec 556 lignes de code, n'a rien à voir avec une question concernant un système théorique de 20 millions de lignes. Sauf peut-être pour démontrer que, aussi difficile soit-il de prouver l'exactitude du programme minuscule, il serait astronomiquement plus difficile de prouver l'exactitude d'un programme massif.
Eric King

9
Bien que la question initiale ne l'ait pas fait, je voudrais souligner qu'il existe une différence gigantesque entre "théoriquement possible" et "pratiquement possible". Même si une base de code exempte de bogues de 20 millions de lignes est théoriquement possible, il s'agit certainement d'une impossibilité pratique sur le marché actuel. Qui sait ce que l'avenir nous réserve.
Eric King

4
@ JohnR.Strohm Vous devriez lire le document plus attentivement. Ils se disent: It is important to note, however, that even all of these steps provide no guarantee of absolute security. It is tempting to believe that a formally specified and proved program should be absolutely correct, but there are several reasons why a proved program may not behave exactly as expected.- ce qui signifie, on ne peut pas prouver qu'il est sans bug, mais plutôt moins susceptible d'avoir des bugs. Plutôt comme TDD.
Izkata

27

Mathématiquement, il PEUT être possible d’écrire un logiciel «sans image» d’une telle complexité, selon la façon dont vous définissez le terme «bug». Prouvons POURRAIENT aussi mathématiquement possible, en concevant un système de test qui exercerait toutes les lignes de code dans toutes les manières possibles - tous les cas possibles d'utilisation. Mais je ne suis pas sûr - si vous utilisez un système qui effectue des calculs complexes, vous risquez de vous heurter à 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 . Il faudra peut-être 1000 ans pour écrire un tel système «sans bug», et pour écrire un système prouvant que cela prendrait exponentiellement plus de temps: il faudrait concevoir chaque cas d'utilisation possible et écrire un système qui testerait chaque système. un - et je ne crois pas qu'il soit possible de déterminer que vous avez réellement couvert chaque cas d'utilisation dans un système de la taille et de la portée dont vous parlez, dans une période qui ressemble à un délai raisonnable.

OMI, votre question est un peu mal dirigée: notre objectif en tant que développeur n'est pas d'écrire un logiciel «sans image». Notre objectif est d’écrire un logiciel USABLE, FLEXIBLE, FACILEMENT MAINTENU .

Utilisable: le système remplit les exigences essentielles pour lesquelles il a été conçu. Il peut y avoir des bugs - mais ce sera dans des "cas extrêmes" - des valeurs aberrantes, ou des ennuis, pas des bugs qui compromettent les fondamentaux du système - robustes.

Maintenable: les bogues peuvent être facilement isolés et corrigés et NE PAS en créer de nouveaux.

Flexible: il est facile de modifier et d’agrandir votre système sans une nouvelle conception et des temps d’immobilisation importants: la plupart des modifications nécessitent simplement l’ajout d’une nouvelle classe ou d’un nouveau module qui s’intègre parfaitement dans vos modèles et votre structure 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 de BON LOGICIEL . (pas parfait - mais BON )


3
"Le prouver POUVANT aussi être possible sur le plan mathématique, en concevant un système de test permettant d’exercer chaque ligne de code de toutes les manières possibles, dans tous les cas d’utilisation possibles.": Un tel programme n’existe pas en général (et cela peut être prouvé!). Donc, un algorithme général pour prouver l'exactitude n'existe pas.
Giorgio

3
Correction: Un logiciel sans bogue, COMPLET AVEC UNE PREUVE MATHÉMATIQUE FORMELLE DE L’EXACTITUDE, a été atteint. Cela a été fait en 1982. Google "modulateur de flux de messages".
John R. Strohm le

6
@ JohnR.Strohm: Ce n'est pas vrai. Voici une citation - il existe plusieurs documents et plusieurs endroits où ils abordent des préoccupations similaires: "Une question qui revient souvent est" Avez-vous vérifié le vérificateur? "Peut-être étonnamment, cette question métamathématique est souvent posée par des ingénieurs non seulement par pointu Bien sûr, si une machine répond jamais à la question "Avez-vous déjà menti?", la réponse ne sera pas plus informative que lorsqu'un humain répond à la question. "
Vecteur

1
Je voulais dire qu’aucun algorithme général ne fonctionnerait pour n’importe quel programme d’entrée et toute spécification d’entrée. Vous ne pouvez gérer que des cas spécifiques (par exemple, votre exemple).
Giorgio

1
@Giorgio - Donc, OMI, suivre les bonnes pratiques de conception est beaucoup plus important que de se préoccuper de l'exactitude mathématique: concevez votre code pour qu'il soit bien intégré et conforme à ce qui existe déjà - et qu'il est suffisamment robuste pour gérer facilement les défauts lorsqu'ils venir à la lumière (ce qu'ils vont).
Vecteur

27

Selon cet article, le logiciel embarqué de la navette spatiale était très proche: les trois dernières versions du programme 420 000 lignes ne comportaient qu'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 permettant à la navette de naviguer avec les satellites de positionnement global n’a concerné que 1,5% du programme, soit 6 366 lignes de code. Les spécifications pour cette modification ont été exécutées sur 2 500 pages. Les spécifications du programme global ont rempli 30 volumes et 40 000 pages, soit une moyenne de dix lignes de code par page de la 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.


25
Une erreur détectée chacun. Qui sait combien d'erreurs non détectées? :)
Andres F.

8
Cette "une erreur" était un cas particulier. La navette a été initialement conçue et spécifiée par le logiciel pour deux bras de robot. L '"erreur" était qu'il restait du code pour soutenir le second bras.
John R. Strohm

4
+1 couru sans erreurs pour 135 missions de 1981 à 2011
MarkJ

5
@MarkJ: nous ne saurions probablement pas si la navette spatiale n'a pas eu d'erreurs. Chaque mission de la navette spatiale est constamment surveillée de manière intensive par des centaines de personnes et toute erreur de codage aurait été corrigée / annulée manuellement.
Lie Ryan

2
@LieRyan Ce qui montre bien l'une des grandes propriétés des systèmes robustes: s'ils n'échouent pas de manière catastrophique et permettent toujours un réglage manuel, vous pouvez utiliser des systèmes redondants (tels que ceux du centre de contrôle) pour effectuer le travail à la place. Bien entendu, cela n’a de sens que si vous disposez de tels systèmes redondants et si vous pouvez réellement vous assurer de leur exactitude et de leur cohérence. Sur une application métier typique, un crash sera souvent préférable à un état incohérent - c'est la différence entre une gêne et, disons, l'envoi d'argent au mauvais gars. Ou recevoir de l'argent sans qu'il soit envoyé ...
Luaan

15

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.

+1: Je cherchais moi-même l’exemple de recherche binaire; j’ai été battu;) Si 20 lignes de code largement discuté et diffusé contenaient un bogue pendant 20 ans, combien de temps faudrait-il pour une base de code de 20 millions de lignes qu’à la plupart des quelques dizaines de personnes occupées regarderont jamais?
scrwtp

Merci. Je me demande si ce bogue de recherche binaire (que je n'ai jamais entendu auparavant) est lié au fait que des personnes copient en collant beaucoup de code sans trop réfléchir. De plus, si nous avons autant de bugs qu'il est même possible d'énumérer, les outils et les pratiques que nous utilisons ne sont peut-être pas optimaux.
Joan Venge

1
@JoanVenge J'ai cité cet exemple pour montrer combien il peut être difficile de trouver des bugs. Dans ce cas, le copier-coller était en fait la bonne chose à faire car il était prouvé que la mise en œuvre avait été écrite à partir de zéro et aurait vraisemblablement plus de bogues. Les outils et les pratiques que nous, en tant qu’industrie en général, utilisons ne sont certainement pas optimaux. Les meilleures pratiques sont faciles à ignorer et les mauvaises habitudes sont faciles à conserver. En fin de compte, les insectes existeront toujours parce que les humains ne sont pas parfaits. Mais nous pouvons réduire le nombre de bugs en faisant de notre mieux et en insistant sur une éducation de haute qualité.
luiscubal

7
Je pense que le bogue dans le code de recherche binaire montre à quel point cette question est complexe. Le bogue sous-jacent de la recherche était un débordement d’entier potentiel dans une addition. De telles "erreurs" sont omniprésentes, car la plupart des gens se fient à une hypothèse implicite (et parfois incorrecte) selon laquelle les entrées ne seront pas assez grandes pour provoquer un débordement. Est-ce vraiment un bug ou juste un contrat d'interface mal documenté? À quand remonte la dernière fois que vous avez vérifié l'étendue des additions d'un entier ou vérifié le dépassement de capacité après cet événement?
Charles E. Grant

4
Vos exemples de serveurs soulignent une observation assez évidente concernant le langage de programmation et la qualité des outils. Un compilateur de qualité production pour un langage robuste aurait dû refuser de compiler votre premier exemple, renvoyant à la place une erreur de compilation fatale. Le fait qu'il soit même POSSIBLE de compiler une telle abomination vous indique tout ce que vous devez savoir sur la qualité de ces outils et sur la faisabilité de leur utilisation pour fournir un logiciel exempt de bogues.
John R. Strohm

12

Les raisons de ne pas écrire de programmes sans bogues 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 spécialement conçus à cet effet. En théorie, programmer sans bugs est possible.

Oui, il existe un matériel imparfait qui peut parfois changer un peu parce qu’un neutrino tiré d’une supernova lointaine il ya 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 mathématiques pour s’assurer que le programme fonctionne correctement.

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 son problème d'arrêt impliquent simplement que vous ne pouvez pas par exemple disposer d'un outil automatisé qui déciderait de l'exactitude ou de l'inexactitude d' un programme. Mais nous ne voulons pas décider de l'exactitude d' un programme, nous voulons seulement la preuve de l'exactitude d' un programme spécifique .

(Par analogie, ce n’est pas parce que vous ne pouvez pas écrire un programme de détermination automatique de la vérité d’ un théorème mathématique que vous ne pouvez pas prouver un théorème mathématique spécifique .)

Le problème, au contraire, est le suivant:

Bien qu’il soit théoriquement possible d’écrire un programme exempt de bogues, cela coûterait très cher . Écrire un code avec la preuve de son exactitude est plus compliqué que de jeter quelque chose sur un mur pour voir s’il reste collé. Même si "voir si ça colle" est fait par des tests unitaires; et beaucoup de programmeurs ne se donnent même pas la peine de le faire. La plupart des programmeurs ne savent même pas comment faire cela, ce qui signifie qu'en tant qu'entreprise, vous devrez en engager des plus onéreuses.

Compte tenu de tous les coûts, un client type 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) plutôt que d’avoir un logiciel mille fois plus cher qui fonctionne bien à 100%. le temps. En outre, le client souhaite disposer de ce logiciel maintenant , et non dans dix ou vingt ans.

Par conséquent, les gens produisent sciemment des logiciels qui ont des risques de bugs, essayant de trouver la combinaison optimale où les bugs ne sont ni trop fréquents ni trop graves, et où la production est suffisamment rapide et bon marché. La combinaison qui procure le plus de profit dans la vie réelle. (Parfois, cela signifie même que vous devez publier un logiciel regorgeant de bogues avant que vos concurrents publient quoi que ce soit, et ne publier qu'une version 2.0 plus décente lorsque vos concurrents sont prêts à publier leur première version décente.)

Si vous bloquez le développement aussi longtemps que nécessaire, pouvez-vous réellement corriger tous les bogues jusqu'à ce qu'il n'y ait plus aucun bogue, si une telle chose pouvait être vérifiée par des ordinateurs?

Mathématiquement, vous pourriez le faire. Économiquement, pourquoi quelqu'un ferait-il cela? Cela signifierait dépenser peut-être vingt ans et quelques millions de dollars. Pendant ce temps, les clients voudraient de nouvelles fonctionnalités et vos applications gelé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.

Raisonner économiquement, c'est bien. Nous vivons dans un monde où l'argent et le temps sont importants. Mais juste parce que nous ne faisons pas quelque chose pour des raisons économiques, nous ne devrions pas dire des bêtises sur le fait que cela ne peut être fait, même en théorie. Qui sait ... peut - être dans quelques années , nous aurons des nouveaux langages de programmation et des outils qui pourraient rendre la justesse prouvant facile .


Merci, bien que je souhaite que la plupart des logiciels fonctionnent 99% du temps, la plupart des gros logiciels que j'utilise, comme celui de OP, est extrêmement bogué. Mais je pense que le monopole et l’achat de concurrents tiennent aussi compte de cela. Mais je vois ton point.
Joan Venge

1
"Cher" est relatif. Comparez le coût de la recherche et de la correction des insectes avec le coût, par exemple, d'un appareil de radiothérapie tuant plusieurs patients et en mutilant plusieurs autres. (Google "Therac 25".)
John R. Strohm

6

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 problème d'Entscheidungs ", qui demandait quelque chose de similaire en termes logiques. Le " premier théorème d'incomplétude " de Kurt_Gödel prouve en 1931 qu'aucune théorie de l'arithmétique élémentaire ne peut être à la fois cohérente et complète. La représentation par Alan Turing du problème d'Entscheidungs ​​en tant que " problème bloquant " a placé la question directement au cœur de la question, dans laquelle il a prouvé qu'il est impossible de prouver qu'un programme sera mené à son terme ou non. Compte tenu de cette indécapabilité, il est également impossible de prouver si un programme a des bugs ou non.

Rien de tout cela ne libère les programmeurs pratiquants parmi nous qui ne cherchent aucun bogue. Cela signifie simplement que nous ne pouvons pas réussir en général.


9
L’indécidabilité ne s’applique qu’en général - il existe des programmes pour lesquels vous ne pouvez prouver ni l’exactitude ni l’inexactitude. Mais pour un programme spécifique donné, la correction (ou plus souvent: la correction) peut souvent être prouvée. En supposant que vous ayez une spécification de langage formelle et un compilateur parfaitement correct, ce dernier n'existe pour aucun langage de programmation de haut niveau, bien que CompCert soit proche.
Daniel

+1 pour citer le fond théorique pertinent. Je ne savais pas encore que le "Entscheidungsproblem" s'appelle le même en anglais qu'en allemand!
Peopleware

5
D'accord avec Daniel. Le défi concerne une seule instance; les problèmes d’arrêt concernent toutes les instances possibles. Il int main() { return 0; } s’arrête pratiquement et est sans bug.
MSalters

1
Le problème de l’arrêt ne dit pas qu’il est impossible de prouver si un programme sera achevé; il dit qu'il existe des programmes pour lesquels il est impossible de prouver. Les programmes quotidiens ordinaires ne font pas partie de cette classe. "Bien que la preuve de Turing montre qu’il ne peut y avoir de méthode ou d’algorithme général pour déterminer si les algorithmes s’arrêtent, il est possible que des instances individuelles de ce problème soient attaquées. Avec un algorithme spécifique, on peut souvent montrer qu’il doit s’arrêter pour toute entrée, et en fait, les informaticiens font souvent cela dans le cadre d’une preuve de correction. "
endolithe

6

Errare humanum est

Même si vous écrivez du code avec un langage formel, comme la méthode B , que vous pouvez utiliser pour prouver mathématiquement que les conditions requises 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.


1
Est-ce toujours un bug quand un programme fait ce qui a été demandé, au lieu de ce qui était prévu?
MSalters

Je pense que c'est ..
Joan Venge

4
@MSalters - Bien sûr que ça l'est. Pas d'un point de vue contractuel, mais finalement le client n'a pas résolu son problème. Voleriez-vous dans un avion dont les ordinateurs font ce qui est demandé mais pas ce qui était prévu?
mouviciel

3

Une bonne partie des «bogues» que j'ai rencontrés pourraient plus précisément être qualifiés d'inadéquations entre la conception du système et les attentes du client.

Maintenant, que nous appelions ces bogues ou non, cela reste académique, mais il reste qu’une bonne partie du travail de maintenance découle directement d’une communication imparfaite et des attentes changeantes des clients.

Même si un système est techniquement, prouvé "correct" dans le sens où il est conforme à une spécification (aussi improbable que cela puisse être pour un logiciel commercial 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.


+1 Un développeur et un client peuvent avoir des points de vue très différents sur ce qui définit un "bogue".
GrandmasterB

Mais que se passe-t-il si le développeur est aussi l'utilisateur? Je trouve généralement le meilleur logiciel de ces personnes en termes de convivialité, car elles savent exactement comment quelque chose devrait fonctionner, etc.
Joan Venge

2

Si vos spécifications sont suffisamment strictes et limitées, vous pourrez peut-être prouver qu'un programme est exempt de bogues, mais uniquement sur la base d'hypothèses non vérifiables sur le fonctionnement correct de tout le reste du système. Cela laisse supposer qu'il n'y a aucun moyen de prouver que les spécifications seraient considérées comme correctes par quiconque posait le problème initial ou par quiconque utilisait le service.


1

J'ai trouvé la section No Bugs de Jim Shore très utile sur ce sujet. La forme abrégée: Il n’est pas possible de développer sans produire des bugs - mais nous pouvons travailler de manière à pouvoir les détecter le plus tôt possible.

Pendant la production du code lui-même. Par exemple, en écrivant et en exécutant fréquemment des tests unitaires au cours du développement, nous veillons constamment à ce que le code fasse ce qu'il est censé faire. En outre, il est utile de réécrire en permanence le code existant de manière à ce qu'il exprime le plus clairement le comportement souhaité du système.

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 système sans bug, vous devez tout d'abord savoir ce qu'est "un bug" pour ce système. Vous pouvez écrire des suites de tests post-hoc assurant la fonctionnalité du système (si elle n’existe pas encore). Le réseau 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, travaillent avec des listes de bogues et de la maintenance pour éliminer les bogues les plus gênants du système.


1

A propos de la vérification par la partie informatique.

Il existe deux manières 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 plus possible, il devient impossible de démontrer qu’un programme n’a pas de bogues, mais seulement qu’il en a. (Et vous avez le problème de montrer que vos tests eux-mêmes ne vérifient pas la présence de bugs).

Pour utiliser un système de preuve, vous commencez par les exigences formelles (et ils peuvent eux-mêmes avoir un bogue, espérons que le langage utilisé pour les exigences conviendra mieux pour vous convaincre qu'il n'y a pas de bogue ici 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 sous - ensembles MISRA-C 2004 de C, plus de nombreuses fonctionnalités exclues par MISRA").


Pour citer Donald Knuth (de mémoire): Vous pouvez prouver qu'un programme est exempt de bogues, mais cela ne veut pas dire qu'il n'a pas de bogues :-)
gnasher729

1

Non, car l'environnement des ordinateurs et des logiciels sur lesquels l'application est exécutée continuera de changer même si le code est gelé. Le système d'exploitation continue d'évoluer avec les correctifs et correctifs, ainsi que les périphériques et les pilotes. Juste au moment où vous pensez avoir atteint le point d'absence de bogues connus, AMD ou nVidia publiera une mise à jour du pilote vidéo qui affecte la manière dont vous interagissez avec le sous-système vidéo. Désormais, votre application présente des défauts visuels (clignotement, scintillement ou réduction de la cadence) pour les clients disposant d’une carte vidéo ou d’une configuration donnée (SLI? LOL).

Outre le matériel et le système d'exploitation, il existe également un certain nombre de produits middleware sous les applications les plus significatives qui évolueront au-delà de votre contrôle, et lorsque vous obtiendrez le code zéro, les couches situées en dessous de vous seront supprimées.

La technologie évolue, de même que les entreprises qui exploitent cette technologie, et l'idée de "libérer" du code n'est ni possible ni réalisable. Les entreprises qui demandent un nouvel ensemble de fonctionnalités ne répondront pas bien à "nous verrons le code verrouillé pendant que nous poursuivons tous les bogues connus et personne ne signalera 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 évoluent et la réponse ne peut pas être "nous avons décidé d'étendre le gel parce qu'Oracle vient de publier un correctif et que nous devons prendre X mois de plus certifier que ".

Non, à un moment donné, l'entreprise recherchera une équipe de développement plus flexible qui prend en charge la nécessité de progresser à la vitesse de la technologie. C’est le problème fondamental des équipes de développement modernes.


0

Oui mais vous ne saurez jamais à coup sûr. Plus vous regardez, plus vous en trouverez. Plus le système utilisé est lourd et plus les cas d'extrémité sont utilisés, plus vous constaterez une autre incompatibilité avec l'intention ou les spécifications d'origine. Cela implique qu'un bug lui-même n'est pas une chose exacte et dépendra souvent de l'interprétation, de la gravité avec laquelle une personne é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 dérangés par quelque chose) et qu'ils y sont totalement adaptés, vous pouvez aussi bien appeler cela sans bug.


-2

Il est possible de fournir systématiquement des logiciels sans bugs, avec une discipline suffisante et une culture d'équipe partagée. (Et un code modulaire bien pondéré, une suite complète de tests automatisés, l’inspection des défauts et l’adaptation de votre processus, et beaucoup d’autres choses qui demandent un effort et de l’humilité mais qui rapportent mille fois.)

Mais ce faisant, vous n’avez généralement pas pour objectif de construire un système à 20 MLOC. Si vous n'avez pas pour objectif d'écrire du code exempt de bogues, vous ne devriez pas non plus créer un système MLOC.

Mon propre raisonnement est le suivant:

Une personne a un besoin à remplir. Une personne (peut-être la même, éventuellement une autre) a un budget pour répondre à ce besoin grâce à un logiciel d’écriture. Toutes ces personnes s'attendent à obtenir des bénéfices pour leur argent.

La personne disposant d'un budget paiera certaines personnes (peut-être les mêmes, éventuellement différentes) appelées programmeurs , de sorte que ces programmeurs transformeront une partie de leur temps convenue en logiciels répondant au besoin.

Ces programmeurs travaillent donc à transformer l’argent de quelqu'un d’autre en logiciel répondant à leurs besoins. C'est leur responsabilité de mettre cet argent à bon escient.

Cela a les implications suivantes en ce qui concerne votre question:

  • Étant donné qu'il y a un bogue dans le logiciel, allez-vous le réparer? Vous avez besoin d'un programmeur pour corriger un bogue, et le programmeur coûtera de l'argent. Un programmeur ne peut pas décider de dépenser de l'argent pour le faire. C'est le rôle de la personne qui détient le budget.
  • Puis-je construire un logiciel 20MLOC à partir de zéro sans laisser de bogues non résolus? Pour construire un 20MLOC, il a fallu dépenser des sommes énormes. C'est financièrement stupide. Et ce n'est pas construit en un jour. Mais les logiciels répondent aux besoins actuels, pas à ceux de demain. Il y aura une tentative malavisée de paralléliser le développement en embauchant beaucoup de programmeurs. Mais alors, il y a fort à parier que vous n'obtiendrez pas une culture partagée et que des bugs s'ensuivront, que le gaspillage et les retards se produiront, et que l'argent sera épuisé pour les réparer. Je n'ai pas encore vu de système sans bug de cette taille. (J'ai vu des systèmes sans bug et des systèmes 20MLOC, mais ils n'étaient pas identiques)
  • Je suis en charge de la maintenance d'un système 20MLOC que je n'ai pas écrit. Pourrais-je atteindre zéro bogue connu? Cela ne dépend pas des programmeurs. Ils ne peuvent pas décider de corriger des bugs parce que ce n'est pas leur argent en jeu. Le retour sur investissement est-il suffisant pour résoudre les bogues restants? Le système existe depuis un certain temps déjà, et les utilisateurs s'y sont habitués et utilisent les bizarreries du système à leur avantage dans leur travail quotidien. Si vous corrigez des bogues par principe, la personne disposant de l'argent devra peut-être payer pour réaménager une fonctionnalité non spécifiée qui a disparu du système, ce qui coûtera encore plus cher.

Tout est une question d'argent, et à juste titre.


-2

Oui.

Mais comme vous le savez, il en faut beaucoup trop pour en valoir la peine.

Avant de pouvoir défendre ma réponse, nous devons d'abord définir ce qu'est un bogue:

  • Un bug est un comportement contraire à la spécification.
  • Cependant, les problèmes dans les spécifications (par exemple, la loi de la robotique) ne comptent pas comme des bogues logiciels.
  • Les fonctionnalités supplémentaires ne comptent pas comme des bogues, sauf si cela est interdit par la spécification.
  • Par souci d'argumentation, les contradictions dans la spécification ne comptent pas non plus comme des bogues logiciels.

Comme vous le savez peut-être déjà, les bonnes architectures logicielles sont modulaires, de sorte que chaque module puisse être testé individuellement (ou manuellement). Grâce à la discipline et à des tests minutieux, il est possible d'écrire des modules individuels qui ne contiennent pas de bugs.

"Mais attendez!" Je vous entends protester: "Et si un comportement inattendu (mais néanmoins correct) d’un module causait un bogue dans un autre?" Ensuite, le bogue est dans le deuxième module. Les modules sans bogues peuvent être traités comme des API et, comme vous le savez, les API nécessitent un certain soin pour être utilisées correctement.

L'écriture de code à l'épreuve des balles nécessite une connaissance approfondie des cas extrêmes et de la logique de flux du développeur, et la plupart des développeurs de logiciels ne sont pas assez intelligents pour apprendre ou ne s'en soucient tout simplement pas. Ou plus souvent, ils sont sur une date limite.

"Mais donnez-moi une place, et je déplacerai le monde." - Archimède


Cela demande des efforts, mais c'est rentable.
Laurent LA RIZZA

1
Si vous laissez les problèmes de spécification en dehors de l'équation, l'ensemble de votre logiciel devient inutile: les spécifications ne sont que des outils permettant de consigner de manière relativement formelle les besoins des utilisateurs, mais c'est l'utilisateur qui doit être satisfait, et non la spécification. Et la création de la spécification fait tout autant partie du développement logiciel que l’écriture du code. Après tout, une spécification formelle complète décrirait le comportement du système, tout comme le code final, mais la spécification n'est tout simplement pas exécutable de manière efficace.
cmaster
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.