Comment être un programmeur zéro-bug? [fermé]

Mon chef m'a toujours dit qu'un bon programmeur devrait être capable de s'assurer que le code qu'il modifie est fiable, correct et entièrement vérifié par lui-même. que vous devez parfaitement comprendre tous les résultats et les conséquences de vos changements. J'ai fait de mon mieux pour être ce genre de programmeur - en testant encore et encore - mais les bugs sont toujours là.

Comment puis-je être un programmeur zéro-bug et savoir ce que chaque caractère de mon code causera et affectera?

Ne code pas du tout.

C'est la seule façon de devenir un programmeur zéro-bug.

Les bogues sont inévitables car les programmeurs sont humains, nous ne pouvons que faire de notre mieux pour les prévenir, réagir rapidement lorsqu'un bogue survient, tirer des leçons de nos erreurs et rester à jour.

Zéro bogue est impossible pour un programme non trivial.

Il est possible de se rapprocher, mais la productivité en souffre. Et cela ne vaut que pour certains logiciels à haut risque. Le logiciel de la navette spatiale me vient à l’esprit. Mais leur productivité est de l'ordre de quelques lignes par jour. Je doute que votre patron veuille ça.

Ce logiciel est sans bug. C'est parfait, aussi parfait que les êtres humains ont atteint. Considérez ces statistiques: les trois dernières versions du programme, chacune longue de 420 000 lignes, ne comportaient qu’une seule erreur. Les 11 dernières versions de ce logiciel comportaient un total de 17 erreurs.

Prenez la mise à niveau du logiciel pour permettre à la navette de naviguer avec les satellites de positionnement global, une modification qui implique seulement 1,5% du programme, soit 6 366 lignes de code. Les spécifications de cette modification comportent 2 500 pages, soit un volume plus épais qu'un annuaire téléphonique. Les spécifications du programme actuel couvrent 30 volumes et 40 000 pages.

"Zero-bug programmer" est un oxymoron, à la manière d'un chanteur silencieux, mais une soixantaine d'années de programmation a produit des fragments de sagesse distillés qui feront de vous un meilleur programmeur, tel que:

• Soyez humble - vous commettez et commettez des erreurs. À plusieurs reprises.
• Soyez conscient de la taille limitée de votre crâne. Abordez la tâche en toute humilité et évitez les ruses intelligentes comme la peste. [Edsger Dijkstra]
• Combattre l' explosion combinatoire
• Débarrassez-vous de l'état mutable (si possible). Oui, apprendre la programmation fonctionnelle.
• Réduire le nombre de chemins de code possibles
• Comprenez (la magnitude) la taille des espaces d'entrée et de sortie (de vos fonctions) et essayez de les réduire afin de vous rapprocher de la couverture de test à 100%
• Supposez toujours que votre code ne fonctionne pas - prouvez-le autrement!

TDD

L’intérêt de TDD est de ne pas écrire une seule ligne de code s’il n’ya pas de test exigeant cette ligne de code. Et pour aller à l'extrême, vous commencez toujours à développer une nouvelle fonctionnalité en écrivant un test d'acceptation. Ici, j'ai trouvé qu'écrire des tests de style concombre est idéal.

L’approche TDD présente au moins deux avantages.

• Tout le code est écrit pour résoudre une caractéristique spécifique, donc pas de surproduction inutile.
• Chaque fois que vous modifiez une ligne de code existante, si vous cassez une fonctionnalité, vous en serez averti.

Cela ne prouve pas zéro bugs, car ce serait impossible (ont déjà été signalés par d'innombrables autres réponses). Mais après avoir appris le TDD et être devenu bon (oui, c’est aussi une compétence qui a besoin de pratique), j’ai beaucoup plus confiance en mon propre code car il est minutieusement testé. Et plus important encore, je peux modifier le code existant que je ne comprends pas complètement sans craindre de perdre des fonctionnalités.

Mais TDD ne vous aide pas du tout. Vous ne pouvez pas écrire de code exempt d’erreurs si vous ne comprenez pas parfaitement l’architecture du système et les pièges de cette architecture. Par exemple, si vous écrivez une application Web qui gère plusieurs demandes simultanément, vous devez savoir que vous ne pouvez pas partager des données mutables entre plusieurs demandes (ne tombez pas dans le piège du débutant pour mettre en cache des données mutables afin d'améliorer les performances).

Je crois que les équipes de développement qui sont bonnes chez TDD fournissent le code avec le moins de défauts possible.

Le problème, c’est que les bugs sont des choses que vous ne reconnaissez pas . À moins que vous ne possédiez une sorte de connaissance encyclopédique du langage de programmation / compilateur ainsi que de tous les environnements dans lesquels votre application s'exécutera, vous ne pouvez vraiment pas vous attendre à produire du code 100% exempt de bogues.

Vous pouvez réduire votre nombre de bogues grâce à de nombreux tests, mais à la fin, il y aura probablement des cas marginaux qui ne seront pas pris en compte. Joel Spolsky a écrit un article particulièrement intéressant sur la résolution des bugs .

Oui, il est impossible de ne jamais avoir de bogue dans votre code mais il n’est pas impossible d’avoir moins de bogues. L'attitude selon laquelle "C'est idiot, vous allez toujours avoir des bogues" n'est qu'un flic pour éviter de réduire le nombre de bogues dans votre code. Personne n'est parfait mais nous pouvons et devons nous efforcer d'être meilleurs. Dans mes propres efforts d'amélioration, j'ai trouvé les points suivants utiles.

• Ce n'est pas facile. Vous ne vous améliorerez pas la nuit. Alors ne vous découragez pas et n'abandonnez pas.
• Ecrivez moins et écrivez plus intelligemment. Moins de code est généralement un meilleur code. Il est naturel de vouloir planifier et d'essayer de créer des modèles de conception impressionnants, mais à la longue, écrire ce dont vous avez besoin permet de gagner du temps et d'éviter les bugs.
• La complexité est l'ennemi. Moins ne compte pas s'il s'agit d'un gâchis compliqué obscur. Le code golf est amusant, mais c’est un enfer à comprendre et un pire à déboguer. Chaque fois que vous écrivez un code compliqué, vous vous ouvrez à un monde de problèmes. Gardez les choses simples et courtes.
• La complexité est subjective. Le code qui était une fois compliqué devient simple une fois que vous devenez un meilleur programmeur.
• L'expérience compte. Une des deux façons de devenir un meilleur programmeur est de pratiquer. La pratique, c’est PAS d’écrire des programmes que vous savez écrire avec facilité, c’est des programmes d’écriture qui vous font mal un peu et vous font réfléchir.
• L'autre façon de s'améliorer est de lire. Il y a beaucoup de sujets difficiles dans la programmation à apprendre, mais vous ne pourrez jamais les apprendre en programmant simplement, vous devez les étudier. Vous devez lire les choses difficiles. Des choses comme la sécurité et la concurrence sont impossibles à apprendre correctement en écrivant du code, sauf si vous voulez apprendre en nettoyant les catastrophes. Si vous ne me croyez pas, regardez les problèmes de sécurité épiques que des sites comme gawker ont eus. S'ils prenaient le temps d'apprendre à faire la sécurité correctement et à ne pas simplement faire quelque chose qui fonctionne, ce gâchis ne serait jamais arrivé.
• Lire des blogs. Il existe une multitude de blogs intéressants qui vous donneront de nouvelles façons intéressantes de regarder et de réfléchir à la programmation, ce qui vous aidera à ...
• Apprenez les détails sales. Les détails mineurs sur la manière dont des parties obscures de votre langage et de votre travail d’application sont très importantes. Ils pourraient avoir des secrets qui vous aideraient à éviter d'écrire du code compliqué ou pourraient être des parties qui ont leurs propres bogues à éviter.
• Apprenez comment les utilisateurs pensent. Parfois, vos utilisateurs sont complètement fous et travaillent avec votre application de manière incompréhensible et impossible à prédire. Vous devez avoir suffisamment conscience de ce qu’ils pourraient essayer d’étranger et s’assurer que votre application peut y faire face.

Personnellement, je pense que lutter pour une programmation exempte de bugs semble être plus coûteux (en temps et en argent). Pour atteindre zéro bogue, voire même un bogue proche de zéro, les développeurs doivent effectuer des tests approfondis. Cela signifie que tout est soumis à un test de régression avant de soumettre un code pour la révision du correctif. Ce modèle ne me semble pas rentable. Il est préférable que les développeurs effectuent les tests appropriés et laissent les tests approfondis à l’équipe d’assurance qualité. Voici pourquoi:

• Les développeurs sont nuls lors des tests. C'est vrai et tu le sais. (Je suis un développeur!) Une bonne équipe d'assurance qualité trouvera toujours les cas extrêmes auxquels les développeurs ne pensent jamais.
• Les développeurs savent bien coder. Laissez-les revenir à ce qu'ils excellent (et généralement ce qu'ils préfèrent faire de toute façon.)
• L'équipe d'assurance qualité peut détecter les bogues liés à plusieurs tâches de développement en une seule fois.

Acceptez le fait que lorsque vous écrivez du code, des bogues seront consignés. C'est pourquoi vous avez un processus d'assurance qualité, et tout cela fait partie du métier de développeur. Bien sûr, cela ne signifie pas que vous soumettez quelque chose dès que vous écrivez votre dernier point-virgule. Vous devez toujours assurer la qualité de votre travail, mais vous pouvez en faire trop.

Combien de professions pouvez-vous nommer pour que leur tâche soit toujours bien faite du premier coup sans examen par des pairs et / ou tests?

Zéro bugs? On dirait que vous avez besoin de Lisp (suivez le chemin sceptique et évitez le clip vidéo).

Il est extrêmement difficile d’obtenir un code exempt de bogues dans les environnements de codage traditionnels (Java, C #, PHP, etc.). Je me concentrerais sur la production de code bien testé et revu par des pairs en de courtes itérations contrôlées.

Garder le code aussi simple que possible vous aidera à éviter les bogues.

Assurez-vous que vous utilisez des outils d'analyse de code (tels que FindBugs , PMD , etc.) qui, combinés à des avertissements stricts du compilateur, vont révéler toutes sortes de problèmes avec votre code. Prenez note de ce qu'ils vous disent, efforcez-vous vraiment de comprendre la nature du bogue, puis prenez des mesures pour modifier votre langage de programmation afin qu'il ne soit pas naturel de coder de manière à réintroduire ce bogue.

Tous les "Ne pas coder du tout." les réponses manquent complètement le point. En outre, votre patron ne semble certainement pas être un crétin!

Je ne me souviens pas combien de fois j'ai vu des programmeurs ne sachant tout simplement pas ce que fait leur code. Leur seule philosophie de développement semblait être des essais et des erreurs (et très souvent aussi des copier / coller / modifier). Bien que les essais et les erreurs constituent un moyen valable de résoudre certains problèmes, vous pouvez souvent analyser le domaine du problème, puis appliquer une solution très spécifique en fonction de votre compréhension des outils que vous utilisez et avec un peu de discipline et de diligence, que vous n'aurez pas a seulement résolu le problème, mais aussi la plupart des cas critiques (bugs potentiels) avant de le déployer pour la première fois. Pouvez-vous garantir que le code est sans bug? Bien sûr que non. Mais avec chaque bogue que vous rencontrez ou lisez, vous pouvez l’ajouter aux choses auxquelles vous voudrez peut-être penser, la prochaine fois que vous écrivez / changez quelque chose. Si vous faites cela, vous gagnerez par conséquent beaucoup d’expérience sur la façon d’écrire du code presque sans bug. - Il existe des tonnes de ressources disponibles sur la façon de devenir un meilleur programmeur pouvant vous aider dans votre cheminement ...

Personnellement, je ne commettrais jamais de code si je ne pouvais pas expliquer chaque ligne. Chaque ligne a sa raison d'être, sinon elle devrait être supprimée. Bien sûr, parfois, vous ferez des suppositions sur le fonctionnement interne des méthodes que vous appelez, sinon vous auriez besoin de connaître la logique interne de tout le framework.

Votre patron a parfaitement raison de dire que vous devez comprendre les résultats et l’impact du code que vous écrivez sur le système existant. Est-ce que les insectes vont se produire? Oui bien sûr. Mais ces bogues seront dus à votre compréhension incomplète du système / des outils avec lesquels vous travaillez et à chaque correction de bogue, vous aurez une meilleure couverture.

Comme les autres commentaires l'ont déjà correctement souligné, il n'y a pas de logiciel non trivial sans bugs.

Si vous voulez tester le logiciel, gardez toujours à l'esprit que ces tests ne peuvent que prouver la présence de bogues et non leur absence.

En fonction de votre domaine de travail, vous pouvez essayer une vérification formelle de votre logiciel. En utilisant des méthodes formelles, vous pouvez être sûr que votre logiciel répond exactement aux spécifications.

Bien sûr, cela ne signifie pas que le logiciel fait exactement ce que vous voulez. Écrire une spécification complète est également impossible dans presque tous les cas. En gros, cela déplace l'endroit où des erreurs peuvent survenir d'une mise en œuvre à une spécification.

Donc, selon votre définition de "bogues", vous pouvez essayer une vérification formelle ou simplement essayer de trouver autant de bogues que possible dans votre logiciel.

Soit vous n’écrivez rien de plus compliqué que "Hello World!" ou si vous dites à tout le monde de ne jamais l'utiliser.

Demandez à votre patron des exemples de ce code dit sans bug.

Je suis d'accord avec les autres. Voici comment j'aborderais le problème

• Obtenez un testeur. Voir le test de Joël pour savoir pourquoi.
• Utiliser abondamment les bibliothèques; les ont probablement été mieux mis au point. Je suis un grand fan de CPAN pour Perl.

Vous pouvez vous efforcer d'être un programmeur zéro bug. Je m'efforce d'être un programmeur zéro bug chaque fois que j'écris du code. Cependant, je ne

• engager plusieurs techniques de test (autres que ATDD)
• créer des vérifications formelles de notre logiciel
• avoir une équipe d'assurance qualité séparée
• faire une analyse approfondie de chaque modification apportée à la base de code
• utiliser un langage qui privilégie la sécurité et la prudence

Je ne fais pas ces choses parce qu'elles coûtent très cher pour les logiciels que j'écris. Si je faisais ces choses, je serais probablement plus loin vers zéro bogue, mais cela n'aurait aucun sens sur le plan commercial.

Je crée des outils internes utilisés par une grande partie de notre infrastructure. Mes normes de test et de codage sont élevées. Cependant, il y a un équilibre. Je ne m'attends pas à zéro bogue parce que je ne peux pas laisser les gens mettre ce genre de temps dans un seul travail. Les choses pourraient être différentes si je créais le logiciel pour contrôler une machine à rayons X, des réacteurs, etc. Il n'y a pas de vie en danger si mon logiciel tombe en panne, nous n'engageons donc pas ce niveau de garantie.

Je ferais correspondre le niveau d'assurance à l'utilisation prévue du logiciel. Si vous écrivez du code que la navette de la NASA utilisera peut-être une tolérance de bogue zéro est raisonnable. Vous avez juste besoin d'ajouter un tas de pratiques supplémentaires très coûteuses.

Je pense qu'un bon premier pas pour devenir un programmeur "zéro bug" est de changer votre attitude envers les bugs. Au lieu de dire «ce qui se passe», «améliorez l'assurance qualité et les testeurs», ou «les développeurs craignent les tests», déclarez:

Les insectes ne sont pas acceptables et je ferai tout ce qui est en mon pouvoir pour les éliminer.

Une fois que cela devient votre attitude, les insectes disparaîtront rapidement. Dans votre recherche de moyens d'éliminer les bogues, vous rencontrerez un développement piloté par les tests. Vous trouverez de nombreux livres, billets de blog et personnes offrant des conseils gratuits sur de meilleures techniques. Vous verrez l'importance d'améliorer vos compétences par la pratique (comme coder des katas ou essayer de nouvelles choses à la maison). Vous commencerez à avoir de meilleures performances au travail parce que vous commencerez à travailler votre métier à la maison. Et, espérons-le, une fois que vous verrez qu'il est possible d'écrire de bons logiciels, votre passion pour votre métier va croître.

En un sens, votre patron a raison. Il est possible d'écrire un logiciel proche de zéro bogue.

Mais le problème est que le coût d’écriture de programmes (presque) zéro-bug est prohibitif . Vous devez faire des choses comme:

• Utilisez des spécifications formelles de vos besoins. Formel, comme dans l’utilisation de Z ou VDM ou d’une autre notation mathématiquement solide.

• Utilisez des techniques de démonstration de théorèmes pour prouver formellement que votre programme implémente la spécification.

• Créez des suites et des harnais complets pour les tests unitaires, de régression et système, ainsi que des harnais pour tester les bogues de toutes les manières. (Et ce n'est pas suffisant en soi.)

• Demandez à de nombreuses personnes d’examiner les exigences (formelles et informelles), les logiciels (et les épreuves). tests et déploiements.

Il est extrêmement improbable que votre patron soit prêt à payer pour tout cela ... ou à supporter le temps nécessaire pour tout faire.

J'ai atteint le statut "zéro bug". Je dis à mes utilisateurs qu'il s'agit d'une fonctionnalité non documentée ou qu'ils demandent une nouvelle fonctionnalité et qu'il s'agit donc d'une amélioration. Si aucune de ces réponses n'est acceptée, je leur dis simplement qu'elles n'ont pas compris leurs propres exigences. Ainsi, il n'y a pas de bugs. Les programmeurs sont parfaits.

Voici les étapes à suivre pour créer un programme sans bug:

1. Ne commencez jamais à coder à moins d’avoir des SPÉCIFICATIONS UNAMBIGUES pour vos fonctionnalités.
2. NE TESTEZ PAS ou ou si vous ne vous fiez pas aux tests pour détecter les défauts du logiciel.
3. Appliquez tous les commentaires sur les défauts découverts lors des tests, des révisions et de la production à un processus et aux développeurs qui ont inséré le défaut en premier lieu. Jeter tous les composants défectueux complètement dès que des défauts sont trouvés. Mettez à jour vos listes de contrôle et formez vos développeurs afin qu'ils ne commettent plus d'erreurs de ce genre.

Les tests ne peuvent que prouver que vous avez des bugs, mais il est généralement inutile de prouver le contraire. En ce qui concerne le retour - si vous avez une machine à fabriquer les pièces qui produit des pièces et que toutes les pièces de 10 secondes en moyenne ont un défaut. Vous pouvez prendre cette pièce, l'aplatir et l'insérer à nouveau dans la machine. pièce qui a fait que le blanc recyclé ne sera pas aussi bon, mais peut-être acceptable. chaque pièce de monnaie de 100 devra être ré-estampillé 2 fois et ainsi de suite. Serait-il plus facile de réparer la machine?

Malheureusement, les gens ne sont pas des machines. Pour réussir, programmeur sans défaut, vous devez investir beaucoup de temps, formation et itération sur chaque défaut fait. Les développeurs doivent être formés aux méthodes de vérification formelles qui sont souvent difficiles à apprendre et à appliquer dans la pratique. Les aspects économiques du développement de logiciels vont également à l'encontre du but recherché: investiriez-vous deux ans dans la formation d'un programmeur capable de réduire le nombre de défauts juste pour le voir passer à un autre employeur? Vous pouvez acheter des machines qui produisent des pièces parfaites ou embaucher 10 autres singes à code pour créer des tests au même coût. Vous pouvez percevoir ce processus exhaustif comme votre "machine", votre atout - investir dans une formation poussée d'excellents développeurs ne rapporte rien.

Bientôt, vous apprendrez à développer un logiciel de qualité acceptable, mais vous ne serez probablement jamais un sans-défaut pour la simple raison qu’il n’existe aucun marché pour un développeur qui fabrique du code parfait parce qu’il est lent.

Programmez de manière défensive: http://en.wikipedia.org/wiki/Programming_de_fensive

Si quelqu'un respecte les conventions de la programmation défensive, les changements seront facilement décelables. Combinez cela avec des rapports de bogue rigoureux pendant le développement et une documentation solide, comme avec doxygen, et vous devriez être en mesure de savoir exactement ce que fait tout votre code et de réparer très efficacement tout bogue qui pourrait survenir.

Cela pourrait-il être le résultat d'une incompréhension d'une bonne méthodologie, et pas seulement de la bêtise générique?

Ce que je veux dire, c'est qu'il est possible que votre patron ait entendu parler de la "méthodologie du zéro défaut" (voir section n ° 5) et ne se soit pas soucié de comprendre ce que cela voulait dire.
Bien sûr, il est gênant pour la direction de retarder le développement de nouvelles fonctionnalités, en faveur de bugs que vous n'auriez pas dû mettre dans ...
Et bien sûr, cela menace son bonus, alors bien sûr, vous n'en obtiendrez pas car "les bons programmeurs ne avoir des bugs "...

C'est bien de faire des bugs, tant que vous pouvez les trouver et les corriger (dans des limites raisonnables, bien sûr).

L'un des concepts fondamentaux des tests de logiciels est que vous ne pouvez JAMAIS être absolument sûr que le programme est parfait. Vous pouvez le valider pour toujours, mais cela ne prouve jamais que le programme est complet car il devient rapidement impossible de tester même avec toutes les combinaisons entrée / variable.

Votre patron semble faire partie de ceux qui "ne comprennent pas ce qui est difficile en programmation, car il suffit de taper"

Si nous supposons que les grands éditeurs de logiciels savent comment obtenir des développeurs de premier ordre (comme dans le cas du programmeur Zero Bugs ), nous pouvons déduire que les logiciels de Microsoft doivent être exempts de bogues. Pourtant, nous savons que c'est loin de la vérité.

Ils développent leur logiciel et, quand ils atteignent un certain niveau de bogues de faible priorité, ils libèrent simplement le produit et les résolvent plus tard.

Sauf si vous développez quelque chose de plus complexe qu'une simple calculatrice, il n'est pas possible d'éviter les bogues tous ensemble. Même la NASA a la redondance sur leurs véhicules et les insectes. Bien qu'ils aient beaucoup de tests rigoureux pour éviter les échecs catastrophiques. Mais malgré tout, ils ont des bugs dans leurs logiciels.

Les insectes sont inévitables, de même que la nature humaine à se tromper.

Ne pas avoir de bogues, c'est comme avoir un système 100% sécurisé. Si un système est sécurisé à 100%, il n’est définitivement plus utile (il repose probablement dans des tonnes et des tonnes de béton et n’est pas connecté à l’extérieur. Pas de système câblé ni sans fil. Il n’existe donc pas de système parfaitement sécurisé. , il n’existe pas de système complexe sans bug.

Je ne vois que des réponses selon lesquelles nous sommes humains et enclins à nous tromper, ce qui est très vrai ... mais je vois votre question sous un autre angle.

Je pense que vous pouvez écrire des programmes sans bugs, mais ce sont généralement des programmes que vous avez déjà écrits 10 ou 12 fois. La 13ème fois que vous écrivez le même programme à partir de zéro, vous savez déjà comment le faire: vous connaissez le problème, vous connaissez les techniques, les bibliothèques, le langage ... vous le voyez dans votre esprit. Tous les modèles sont là, à tous les niveaux.

Cela me arrive avec des programmes très simples parce que j'enseigne la programmation. Ils sont simples pour moi, mais difficiles pour les étudiants. Et je ne parle pas de solutions aux problèmes que j'ai souvent abordés au tableau. Bien sûr que je les connais. Je veux dire environ 300 programmes qui résolvent quelque chose en utilisant des concepts que je connais très bien (les concepts que j'enseigne). J'écris ces programmes sans planification et ils fonctionnent, et j'ai l'impression de connaître tous les détails, je n'ai pas du tout besoin de TDD. Je reçois deux ou trois erreurs de compilation (principalement des fautes de frappe et d'autres choses du même genre) et c'est tout. Je peux le faire pour de petits programmes, et je pense aussi que certaines personnes peuvent le faire pour des programmes plus compliqués. Je pense que des gens comme Linus Torvalds ou Daniel J. Bernstein ont une telle clarté d’esprit, c’est le meilleur moyen d’obtenir un codeur sans bugs. Si vouscomprendre les choses profondément, je pense que vous pouvez le faire. Je ne peux le faire que pour des programmes simples, comme je l'ai dit.

Ma conviction est que si vous essayez toujours de faire des programmes bien au-dessus de votre niveau (j'ai déjà passé des années à le faire), vous risquez de vous perdre et de faire des erreurs. De grosses erreurs comme celles dans lesquelles vous réalisez soudainement que votre solution ne peut pas fonctionner, lorsque vous comprenez enfin le problème et devez effectuer des modifications si compliquées qu'elles risquent de vous empêcher de résoudre votre problème ou de rendre le code horrible. TDD est pour ces cas, je crois. Vous savez que vous ne résolvez pas le problème que vous abordez et que vous mettez donc des tests partout pour vous assurer que vous disposez d'une base solide. TDD ne résout cependant pas la vision de 10 000 pieds. Vous pourriez marcher en rond avec un code parfaitement propre tout le temps.

Cependant, si vous essayez de faire quelque chose de nouveau, mais juste au - dessus de votre niveau, votre programme pourrait être parfait ou presque parfait. Je pense qu'il est vraiment difficile de savoir quels sont les programmes qui se trouvent dans votre "frontière du savoir", mais en théorie, c'est la meilleure façon d'apprendre. En fait, je réécris beaucoup de programmes à partir de rien. Certaines personnes le font, mais vous avez besoin de beaucoup de temps et de patience car la troisième fois que vous répétez un programme non trivial, vous ne vous énervez pas autant que la première fois.

Mon conseil est donc le suivant: ne pensez pas que vous comprenez quelque chose tant que vous ne pourrez pas écrire un programme exempt d'erreurs rien que pour cela. Et essayez ensuite de combiner deux de ces concepts que vous connaissez profondément dans le même programme. Je suis presque sûr que vous aurez bien compris la première fois. L'un des meilleurs moyens consiste à réécrire des logiciels non triviaux, ce qui a demandé beaucoup d'efforts dès la première fois (je le fais actuellement avec les applications Android). Chaque fois que je recommence, je change quelque chose ou j'ajoute des choses, juste pour ajouter un peu de plaisir, et je peux vous dire que je vais de mieux en mieux ... peut-être pas sans insectes mais vraiment fier.

des bogues imho et des artefacts d'algorithmes soudains et mystérieux doivent apparaître pendant le processus de codage: ils inspirent et forcent l'évolution du code.
Cependant, il est possible (généralement après quelques tests) de vérifier chaque variable pouvant être utilisée avant la déclaration, de gérer chaque erreur, où qu'elle apparaisse - de rendre le programme zéro bogue ... jusqu'à ce que vous receviez une demande pour une fonctionnalité qui a été considérée impossible lorsque vous discutiez de l'architecture du programme;)

Peut-être réfléchissez-vous davantage à la nature des bugs que vous rencontrez. Si les bogues sont généralement des oublis mineurs, il serait utile de mettre l'accent sur de meilleurs tests et un peu de relecture de code.

Si les bogues ont tendance à être dus à des décisions de programmation sous-optimales, vous devrez peut-être consacrer plus d'efforts à une meilleure conception. Dans ce cas, je pense qu'il est possible de trop dépendre des tests pour améliorer la qualité du logiciel, car l'application d'un correctif à un code déficient peut simplement compliquer la maintenance future. D'un côté, vous obtenez moins de bugs lorsque vous les trouvez et les corrigez, mais de l'autre, vous préparez le terrain pour les futurs bugs.

Une façon de déterminer si vous avez un problème d’oubli ou un problème de conception consiste à déterminer l’ampleur des efforts nécessaires pour résoudre le problème. Si les correctifs ont tendance à être volumineux ou si vous avez l’impression que vous ne les comprenez pas bien, il est alors possible d’améliorer la conception du code.

Je pense que cela revient à une sorte de bon goût pour le code, que vous pouvez développer avec la pratique et la critique, et en lisant sur les personnes ayant des problèmes similaires.

En fin de compte, il est vain de s’attendre à ce qu’il n’y ait aucun bogue, mais il n’ya aucun mal à essayer de réduire votre nombre de bogues à moins que vous ne l’ayez déjà à un niveau bas. Cela devient alors un compromis entre votre temps et celui de celui qui trouve des insectes que vous ne détectez pas.

Si je vous veux dire: "zéro bogue lors de l'écriture du code" -> c'est un objectif intéressant mais plutôt impossible.

Mais si vous voulez dire: "zéro bogue sur le code livré" -> c'est possible, et j'ai travaillé dans de tels environnements.

Tout ce dont vous avez besoin est: une qualité de code incroyablement élevée et une couverture de test proche de 100% (tests unitaires + tests de réception + tests d'intégration).

À mon avis, le meilleur livre à apprendre est le GOOS . Mais bien sûr, un livre ne suffit pas. Vous devez consulter un groupe d'utilisateurs et en discuter. Cours, conférences, etc. La qualité zéro bug n'est pas facile.

Tout d'abord, vous avez besoin d'un chef qui s'intéresse vraiment à la qualité et qui est prêt à payer pour cela.

Solution du programmeur:

• Arrêtez la programmation.
• Construire un ordinateur mécanique.
• Remplacez-le tous les 5 ans afin d'éviter toute usure mécanique.

Solution de l'utilisateur:

• Arrêtez d'utiliser des ordinateurs.
• Faites tout manuellement.
• Toujours demander à une deuxième personne de vérifier les résultats.

Je conviens que pour être un programmeur zéro-bug, vous ne pouvez tout simplement pas programmer / coder. Rencontrer et développer des bugs fait partie de la vie de chaque programmeur. Aucun développeur expérimenté ne peut dire, cœur sur la main, qu’ils n’ont jamais rencontré de bogue dans leur code.

Paire avec un autre ingénieur. Ecrivez un test qui échoue. Avez-vous besoin de chaque caractère que vous tapez pour réussir le test échoué. Refactorisez votre code pour le rendre plus simple. Ecrivez un autre test qui échoue, et ainsi de suite.