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.

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=---

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 )

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.

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.

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 .

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.

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.

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.

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.

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.

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").

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.

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.

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.

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