Existe-t-il une application sans bogue? [dupliquer]

Plus vous vous rapprochez dune application sans bogue, la plus cher ça devient. Cest comme si vous visiez une couverture de code à 100%: vous dépensez autant de temps et dargent pour passer de 0% à 95%, de 95% à 99% et de 99% à 99,9%.

Avez-vous besoin de ce 0,1% supplémentaire de couverture de code ou de qualité? Probablement oui, si vous « travaillez sur un logiciel qui contrôle le système de refroidissement dun réacteur nucléaire. Probablement pas si vous « travaillez sur une application métier.

De plus, la création de logiciels de haute qualité nécessite une approche très différente . Vous ne pouvez pas simplement demander à une équipe de développeurs qui ont passé leur vie à écrire des applications professionnelles de créer une application pratiquement sans bogue. Un logiciel de haute qualité nécessite différentes techniques, telles que la preuve formelle , quelque chose que vous ne voulez certainement pas utiliser dans une application professionnelle, en raison du coût extrêmement élevé que cela représente.

Comme je lai expliqué dans , lun des mes articles :

• Les applications professionnelles ne devraient « pas cibler la qualité requise pour les logiciels vitaux, car si ces applications professionnelles échouent de temps en temps, elles ne le font tout simplement pas » Jai vu des bogues et des temps darrêt sur les sites Web de probablement toutes les grandes entreprises, Amazon étant la seule exception. Ce temps darrêt et ces bugs sont ennuyeux et peuvent coûter à lentreprise quelques milliers de dollars par mois, mais le réparer serait beaucoup plus coûteux.

• Le coût devrait être lobjectif principal, et devrait être étudié de manière pragmatique. Imaginons un bug qui affecte 5 000 clients et est si important que ces clients partiront pour toujours. Est-ce important? Oui? Réfléchissez plus. Et si je dis que chacun de ces clients paie 10 $ par an et quil le fera a coûté près de 100 000 $ pour corriger le bogue? La correction du bogue semble maintenant beaucoup moins intéressante.

Maintenant, pour répondre spécifiquement à vos questions:

Pourquoi les bogues sont-ils signalés même après avoir subi tant de tests? Est-ce notre problème? Notre client ne semble pas satisfait de tout ce que nous fournissons? faisons-nous quelque chose de mal?

Beaucoup de choses peuvent mal tourner. Par tests, voulez-vous dire des tests automatisés réels? Sinon, cest un énorme problème en soi. Les testeurs comprennent-ils les exigences? Communiquez-vous régulièrement avec le client – au moins une fois par itération, au mieux le représentant client est immédiatement joignable sur place par nimporte quel membre de votre équipe ? Vos itérations sont-elles suffisamment courtes? Les développeurs testent-ils leur propre code?

De la même manière que Ils écrivent le bon article lié ci-dessus, rédige un rapport de bogue et étudie pourquoi ce bogue est apparu en premier lieu et pourquoi il a été manqué par chaque testeur . Cela peut vous donner quelques idées sur les lacunes dans le processus de votre équipe.

Point important à considérer: votre client paie-t-il pour les corrections de bogues? Sinon, il peut être encouragé à envisager de être un bogue. Lui faire payer le temps que vous passez sur les bogues réduira alors considérablement le nombre de rapports de bogues.

Quelquun a-t-il développé une application qui a été totalement exempt de bogues? Quel est le processus? Pourquoi ne pouvons-nous pas déployer lapplication avec des bogues mineurs? Sommes-nous censés être perfectionnistes?

Moi. Jai écrit une application pour moi-même le week-end dernier et je nai pas trouvé de bogue jusquà présent.

Les bogues ne sont que des bogues lorsquils sont signalés. Donc en théorie, avoir une application sans bogue est tout à fait possible: si elle nest utilisée par personne, il ny aura personne pour signaler les bogues.

Maintenant, écrire une application à grande échelle qui correspond parfaitement au spécification et sest avérée correcte (voir la preuve formelle mentionnée ci-dessus) est une autre histoire. Sil sagit dun projet vital, cela devrait être votre objectif (ce qui ne signifie pas votre application sera sans bogue).

Le scénario actuel est-il le bon processus de développement et de test? Sinon, quel est le moyen efficace pour que les développeurs, les testeurs et les clients obtiennent le maximum davantages ensemble?

1. Afin de se comprendre , ils devraient communiquer. Ce nest pas ce qui se passe dans la plupart des entreprises que jai vues. Dans la plupart des entreprises, le chef de projet est le seul à parler au client (parfois à un représentant).Ensuite, il partage (parfois partiellement) sa compréhension des exigences avec les développeurs, les concepteurs dinteractions, les architectes, les DBA et les testeurs.

   Cest pourquoi il est essentiel que le client (ou le représentant du client) être joignable par nimporte qui de léquipe (approche Agile) ou disposer de moyens de communication formels qui autorisent une personne à ne communiquer quavec quelques autres personnes dune équipe et à le faire de manière à ce que linformation puisse être partagée avec toute léquipe, sassurer que tout le monde dispose des mêmes informations.

2. Il existe de nombreux processus de développement et de test. Sans connaître précisément lentreprise et léquipe, il ny a aucun moyen de déterminer lequel doit être appliquée dans votre cas. Pensez à engager un consultant ou à embaucher un chef de projet suffisamment compétent.

Commentaires

• +1. Avant même de démarrer un projet, vous devez comprendre ce qui est " assez bon pour la publication " et construisez en conséquence.
• @JuliaHayward Pourrait ' être plus daccord. Le jeu final ici est n ' t zéro défaut – il produit un logiciel fonctionnel qui ajoute de la valeur en temps opportun.

Tous les bogues ne sont pas créés égaux, vous devez donc trier le bon grain de livraie.

Attentes

De nombreux bogues sont soulevés simplement en raison dun manque dans ce que fait le logiciel et ce que lutilisateur final attend. Cette attente vient de plusieurs domaines: utilisation dautres logiciels, documentation incorrecte, personnel de vente trop zélé, comment le logiciel fonctionnait, etc.

Scope fluage

Il va sans dire que plus vous livrez, plus le potentiel de bogues est grand. De nombreux bugs sont simplement soulevés à cause des nouvelles fonctionnalités. Vous livrez X & Y mais le client dit que sur le dos de celui-ci, il devrait maintenant aussi faire Z.

Comprendre le domaine du problème

De nombreux bogues surviennent pour la simple raison que le domaine du problème était mal compris. Chaque client a ses propres règles commerciales, jargon et façons de faire. Une grande partie de cela ne sera documentée nulle part – ce ne sera que dans la tête des gens. Avec la meilleure volonté du monde, vous ne pouvez pas espérer capturer tout cela en un seul passage.

Alors … que faire.

Tests unitaires automatisés

De nombreux bogues sont introduits comme un effet secondaire inattendu dun changement de code ou autre. Si vous ont des tests unitaires automatisés, vous pouvez éviter bon nombre de ces problèmes et produire un meilleur code dès le départ.

Les tests ne sont aussi bons que les données fournies – assurez-vous donc de bien comprendre le domaine du problème.

Couverture du code

Cela va de pair avec les tests unitaires automatisés. Vous devriez assurez-vous que le plus de code possible est testé.

Apprenez les leçons

Madness fait la même chose encore et encore et encore et attend des résultats différents

Comprenez-vous les causes du dernier échec? Vraiment? Vous avez peut-être arrêté le problème mais quelle était la véritable source racine? De mauvaises données? Erreur utilisateur? La corruption du disque? Panne de réseau?

Rien ne gêne plus les clients que de rencontrer les mêmes problèmes encore et encore sans progresser vers une forme de résolution.

Des défauts existent depuis le début du développement logiciel. Il est difficile de dire à partir de votre question dans quelle mesure et quelle gravité les défauts affectent la convivialité ou la fonctionnalité.

Des programmes sans défaut existent, mais à peu près tout système non trivial aura des défauts.

Vous devrez décider dune sorte de hiérarchisation et vous devrez probablement faire une étude de la cause des défauts – où ils ont été introduits. Il y a beaucoup trop de choses à discuter de ces choses dans un simple Q & Un article.

Des livres entiers ont été écrits sur lanalyse causale et le processus de résolution dune organisation qui a des problèmes de qualité.

Donc ma recommandation est de: (sans ordre particulier)

• Mettre en œuvre un système de suivi des défauts si vous nen avez pas déjà trouvé
• Déterminer un moyen de classer la gravité des défauts
• Déterminez pourquoi vous ne répondez pas aux attentes des clients (sagit-il des développeurs, du QA, du client, etc.)
• Découvrez certains exercices tels que les «cinq pourquoi» et faites une enquête similaire ation dans certaines des causes de vos défauts.

Dépend de ce que vous appelez une application.

Si vous voulez dire, un programme interactif où vous devez être certain que le comportement en temps réel est exactement tel ou tel dans des circonstances données, alors il est fondamentalement impossible de prouver quil ny a pas de bogues dedans. Je suppose que ce serait possible si vous pouviez résoudre le problème darrêt , mais vous ne pouvez pas « t.

Cependant, si vous vous limitez à une déclaration de « telle ou telle entrée finira par produire tel ou tel état final », alors vos chances dune « preuve sans bogue » sont meilleures, car vous pouvez utiliser des invariants . Cela, et seulement cela, permet de décomposer une preuve dexactitude en sous-problèmes, dont chacun peut être relativement facilement prouvé comme fonctionnant correctement dans toutes circonstances du programme restant (bien que vous ne puissiez généralement pas être très précis sur le temps & que cela pourrait prendre).

De telles techniques sont fondamentalement possibles dans tout langage de programmation (bien que certains ésotériques comme Malbolge essaient de réfuter cela !), mais dans tous les langages impératifs, cela devient très vite compliqué, parce que vous devez suivre méticuleusement beaucoup de état implicite du programme. Dans les langages fonctionnels ¹ , les preuves ont tendance à être beaucoup plus jolies ( langages purs , ou le sous-ensemble purement fonctionnel dun langage). Néanmoins, en particulier avec les types dynamiques, vous devrez rédiger de nombreuses exigences sur les entrées autorisées. Cest bien sûr lun des principaux avantages des systèmes de type statique forts: les exigences sont là dans le code!
Eh bien, idéalement, cest-à-dire. En pratique, les programmes O « Caml ou même Haskell ont tendance à contenir fonctions non totales , cest-à-dire des fonctions qui planteront / se bloqueront / lanceront pour certaines entrées, malgré le type correct ² . Parce que même si ces langages ont des systèmes de type très flexibles, il est parfois impossible de les utiliser pour restreindre complètement quelque chose.

Entrez langages à typage dépendant ! Ceux-ci peuvent « calculer » les types avec précision selon les besoins, de sorte que tout ce que vous définissez peut avoir exactement la signature de type qui prouve tout ce dont vous avez besoin. Et en effet, les langues à typage dépendant sont principalement enseignées comme des environnements de preuve . Malheureusement, je pense qu’aucun d’entre eux n’est vraiment à la hauteur pour écrire un logiciel de production. Pour les applications pratiques, je pense que le plus proche de la protection contre les bogues est d’écrire en Haskell avec des fonctions aussi complètes que possible. Cela vous rend joli proche de la protection contre les bogues – mais, encore une fois, uniquement en ce qui concerne la description fonctionnelle. Haskell « La manière unique de gérer les E / S avec les monades donne également des preuves très utiles, mais elle ne vous dit généralement rien sur le temps que cela prendra terminer. Très probablement, quelque chose peut prendre un temps exponentiel dans des circonstances particulières – du POV de lutilisateur, ce serait probablement un bogue aussi grave que si le programme se bloquait complètement.

¹ _{Ou plus généralement, des langages descriptifs . Je nai pas beaucoup dexpérience avec les langages logiques, mais je suppose quils peuvent être tout aussi agréables en preuve Cordialement.}

² _{Si ce nest pas le type correct, le compilateur ne lautorisera jamais dans ces langues; cela élimine déjà beaucoup de bogues (et, grâce à linférence de type Hindley-Milner, cela rend également les programmes plus concis!)}

Commentaires

• " Si vous voulez dire, un programme interactif où vous devez être certain que le comportement en temps réel est exactement tel ou tel dans toutes les circonstances, alors il ' est fondamentalement impossible de prouver quil ny a ' aucun bogue dedans. Je suppose que ce serait possible si vous pouviez résoudre le problème darrêt, mais vous pouvez ' t. ": Je ne sais pas si la déclaration est correcte. Il est impossible de vérifier un programme arbitraire , mais quen est-il dun programme que vous avez écrit de manière à permettre une telle vérification?
• Voir par exemple cs.cmu.edu/~rwh/smlbook/book.pdf , au début de la page 198: " Enfin, il est important de noter que la spécification, la mise en œuvre et la vérification vont de pair. Il nest pas réaliste de proposer de vérifier quun morceau de code arbitraire satisfait une spécification arbitraire. Les résultats fondamentaux de calculabilité et de complexité montrent clairement que nous ne pourrons jamais réussir dans une telle entreprise. Heureusement, il est également complètement artificiel. En pratique, nous spécifions, codons et vérifions simultanément, chaque activité informant lautre."
• @Giorgio: bien sûr, vous pouvez écrire certains programmes dune manière qui permet une telle vérification , mais cela vous restreint vraiment beaucoup. Dans un gros programme, vous ' aurez presque toujours besoin dexploiter lexhaustivité de Turing quelque part. – Oui, en pratique vous spécifiez, codez et " vérifiez " simultanément, mais cette vérification est souvent assez heuristique (basée par exemple sur des tests unitaires , pas de vraies preuves).
• Quentendez-vous par " exploitant lexhaustivité de Turing "?
• " … mais cette vérification est souvent assez heuristique (basée par exemple sur des tests unitaires, pas de vraies preuves) ": Non , si vous lisez attentivement les notes, il parle de prouver lexactitude au moyen de méthodes formelles (par exemple en utilisant linduction), il ne parle pas de tests unitaires. Voir aussi compcert.inria.fr/doc .