Comment être un programmeur zéro bug?
Mon patron m'a toujours dit qu'un bon programmeur devrait être en mesure de s'assurer que le code qu'il modifie est fiable, correct et entièrement auto-vérifié; que vous devez bien comprendre tous les résultats et les impacts que vos changements entraîneront. 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 provoquera et affectera?
Ne codez pas du tout.
C'est la seule façon de devenir un programmeur zéro bug.
Les bogues sont inévitables parce que les programmeurs sont humains, tout ce que nous pouvons faire est de faire de notre mieux pour les prévenir, réagir rapidement lorsqu'un bogue se produit, apprendre de nos erreurs et rester à jour.
Zéro bogue est impossible pour un programme non trivial.
Il est possible de s'approcher de très près, 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 bogue. Il est parfait, aussi parfait que l'ont été les êtres humains. Considérez ces statistiques: les trois dernières versions du programme - chacune 420 000 lignes de long - avaient une seule erreur chacune. Les 11 dernières versions de ce logiciel avaient un total de 17 erreurs.
Prenez la mise à niveau du logiciel pour permettre à la navette de naviguer avec Global Positioning Satellites, un changement qui implique seulement 1,5% du programme, ou 6 366 lignes de code. Les spécifications de ce changement couvrent 2 500 pages, un volume plus épais qu'un annuaire téléphonique. Le cahier des charges du programme actuel contient 30 volumes et compte 40 000 pages.
"Programmeur Zero-bug" est un oxymore, comme un chanteur silencieux, mais au cours des 60 dernières années de programmation, il a produit quelques morceaux de sagesse distillés, qui feront de vous un meilleur programmeur, tels que:
- Soyez humble - vous faites et ferez des erreurs. À plusieurs reprises.
- Soyez pleinement conscient de la taille limitée de votre crâne. Abordez la tâche en toute humilité et évitez les astuces intelligentes comme la peste. [Edsger Dijkstra]
- Combat explosion combinatoire
- Débarrassez-vous de l'état mutable (si possible). Oui, apprenez la programmation fonctionnelle.
- Réduisez le nombre de chemins de code possibles
- Comprendre (l'ampleur de) la taille des espaces d'entrée et de sortie (de vos fonctions), et essayer de les réduire afin de se rapprocher toujours plus de la couverture de test à 100%
- Supposez toujours que votre code ne fonctionne pas - prouvez-le autrement!
TDD
Le point de TDD est que vous n'écrivez pas une seule ligne de code s'il n'y a pas de test nécessitant 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é que l'écriture de tests de style concombre est idéale.
L'approche TDD offre 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 serez averti
Cela ne prouve pas zéro bogue, car cela serait impossible (ont déjà été signalés par d'innombrables autres réponses). Mais après avoir appris le TDD et devenir bon dans ce domaine (oui, c'est aussi une compétence qui nécessite de la pratique), j'ai une confiance beaucoup plus élevée dans mon propre code car il est minutieusement testé. Et plus important encore, je peux changer le code existant que je ne comprends pas complètement sans me soucier de casser les fonctionnalités.
Mais TDD ne vous aide pas tout du long. Vous ne pouvez pas écrire de code sans bogue si vous ne comprenez pas bien 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 débutant pour mettre en cache les données mutables pour améliorer les performances).
Je crois que les équipes de développement qui sont douées pour TDD livrent le code avec le moins de défauts.
Le fait est que les bogues sont les choses que vous ne reconnaissez pas . À moins que vous ayez 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% sans bogue.
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 agréable sur correction de 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 que "c'est idiot, tu vas toujours avoir des bugs" est juste un flic pour éviter de réduire le nombre de bugs dans votre code. Personne n'est parfait, mais nous pouvons et devons nous efforcer d'être meilleurs. Dans mes propres efforts pour m'améliorer, j'ai trouvé les points suivants utiles.
- Ce n'est pas facile. Vous ne vous améliorerez pas pendant la nuit. Alors ne vous découragez pas et n'abandonnez pas.
- Écrivez moins et écrivez plus intelligemment. Moins de code est généralement meilleur. Il est naturel de vouloir planifier à l'avance et d'essayer de créer des modèles de conception impressionnants, mais à long terme, le simple fait d'é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 si c'est un désordre obscur et compliqué. Le golf de code est amusant mais c'est un enfer à comprendre et un pire enfer à déboguer. Chaque fois que vous écrivez du code compliqué, vous vous ouvrez à un monde de problèmes. Gardez les choses simples et courtes.
- La complexité est subjective. Un code autrefois compliqué devient simple une fois que vous devenez un meilleur programmeur.
- L'expérience compte. L'une des deux façons de devenir un meilleur programmeur est de pratiquer. La pratique n'est PAS d'écrire des programmes que vous savez écrire facilement, mais d'écrire des programmes qui vous font un peu mal 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 simplement en programmant, vous devez les étudier. Vous devez lire les trucs durs. Des choses comme la sécurité et la concurrence sont impossibles à apprendre correctement en écrivant simplement 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 Gawker avait. S'ils prenaient le temps d'apprendre à faire correctement la sécurité et pas seulement à faire quelque chose qui fonctionnait, ce gâchis ne se serait jamais produit.
- Lisez les blogs. Il existe une tonne de blogs intéressants qui vous donneront de nouvelles façons intéressantes de regarder et de penser à la programmation, cela vous aidera à ...
- Apprenez les petits détails. Les détails mineurs sur la façon dont les parties obscures de votre langage et de votre application sont très importants. Ils peuvent contenir des secrets qui vous aident à éviter d'écrire du code compliqué ou peuvent être des parties qui ont leurs propres bogues que vous devez éviter.
- Découvrez comment les utilisateurs pensent. Parfois, vos utilisateurs sont complètement fous et travailleront avec votre application d'une manière que vous ne comprenez pas et que vous ne pouvez pas prévoir. Vous devez vous mettre en tête suffisamment pour connaître les choses étranges qu'ils pourraient essayer et vous assurer que votre application peut les gérer.
Zéro bogue? Cela ressemble à vous avez besoin de LISP (suivez le chemin sceptique et évitez le clip).
Il est extrêmement difficile d'obtenir un code sans bogue dans les environnements de codage traditionnels (Java, C #, PHP, etc.). Je me concentrerais sur la production de code bien testé et évalué par les pairs dans de courtes itérations contrôlées.
Garder le code aussi simple que possible vous aidera à éviter les bugs.
Assurez-vous que vous utilisez des outils d'analyse de code (tels que FindBugs , PMD et ainsi de suite) qui, combiné à des avertissements stricts du compilateur, révélera 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 changer votre idiome de programmation afin qu'il ne soit pas naturel de coder d'une manière qui réintroduit ce bogue.
Personnellement, je pense que rechercher une programmation sans bug semble être plus cher (en temps et en argent). Afin d'atteindre zéro bug, voire un bug proche de zéro, vous devez faire tester les développeurs à fond. Cela signifie tout tester de régression avant de soumettre un code pour examen des correctifs. Ce modèle ne me semble pas rentable. Il vaut mieux que les développeurs effectuent des tests diligents et laissent les tests approfondis à l'équipe QA. Voici pourquoi:
- Les développeurs craignent les tests. C'est vrai et tu le sais. (Je suis développeur!) Une bonne équipe d'assurance qualité trouvera toujours les cas Edge auxquels les développeurs ne pensent jamais.
- Les développeurs savent bien coder. Laissez-les revenir à ce qu'ils font (et généralement ce qu'ils préfèrent de toute façon.)
- L'équipe QA peut trouver des bogues liés à plusieurs tâches de développeur en un seul passage.
Acceptez que lorsque vous écrivez du code, il y aura des bogues enregistrés contre lui. C'est pourquoi vous avez un processus d'assurance qualité, et cela fait partie du fait d'être 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 garantir la qualité de votre travail, mais vous pouvez en faire trop.
Combien de professions pouvez-vous nommer qui accomplissent toujours leur tâche correctement la première fois sans examen par les pairs et/ou tests?
Tous les "Ne pas coder du tout." les réponses manquent complètement. De plus, votre patron ne semble certainement pas être un crétin!
Je ne me souviens pas combien de fois j'ai vu des programmeurs qui ne savaient tout simplement pas ce que fait leur code. Leur seule philosophie de développement semblait être des essais et erreurs (et très souvent aussi copier/coller/modifier). Bien que les essais et erreurs soient 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, vous n'aurez pas seulement résolu le problème mais aussi la plupart des cas d'angle (bogues potentiels) avant de le déployer pour la première fois. Pouvez-vous garantir que le code est exempt de bogues? Bien sûr que non. Mais avec chaque bug que vous rencontrez ou lisez, vous pouvez l'ajouter aux choses auxquelles vous voudrez peut-être penser la prochaine fois que vous écrivez/modifiez quelque chose. Si vous faites cela, vous gagnerez par conséquent beaucoup d'expérience sur la façon d'écrire du code qui est presque exempt de bogues. - Il y a des tonnes de ressources disponibles sur la façon de devenir un meilleur programmeur qui peut vous aider sur le chemin ...
Personnellement, je ne commettrais jamais de code où je ne peux pas expliquer chaque ligne. Chaque ligne a une raison d'être, sinon elle doit être supprimée. Bien sûr, parfois, vous ferez des hypothèses sur le fonctionnement interne des méthodes que vous appelez, sinon vous auriez besoin de connaître la logique interne de l'ensemble du cadre.
Votre patron a tout à fait raison de dire que vous devez comprendre les résultats et l'impact du code que vous écrivez sur le système existant. Des bogues se produiront-ils? Oui bien sûr. Mais ces bogues seront dus à votre compréhension incomplète du système/des outils avec lesquels vous travaillez et avec 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 souhaitez tester le logiciel, gardez toujours à l'esprit que ces tests ne peuvent que prouver la présence de bugs et non leur absence.
Selon 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. La rédaction d'une spécification complète est également impossible dans presque tous les cas. Il déplace essentiellement l'endroit où des erreurs peuvent survenir de l'implémentation à la spécification.
Ainsi, selon votre définition de "bogues", vous pouvez essayer une vérification formelle ou simplement trouver autant de bogues que possible dans votre logiciel.
Soit n'écrivez rien de plus compliqué que "Hello World!" ou si vous dites à tout le monde de ne jamais l'utiliser.
Demandez à votre patron quelques exemples de ce soi-disant code sans bogue.
Je suis d'accord avec les autres. Voici comment j'aborderais le problème
- Obtenez un testeur. Voir le test Joel pour savoir pourquoi.
- Utiliser largement les bibliothèques; les ont probablement été mieux débogués. 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 (autre qu'ATDD)
- créer des vérifications formelles de notre logiciel
- avoir une équipe d'assurance qualité distincte
- effectuer une analyse approfondie de chaque modification apportée à la base de code
- utiliser un langage plus orienté vers la sécurité et la prudence
Je ne fais pas ces choses parce qu'elles sont d'un coût prohibitif pour le logiciel que j'écris. Si je faisais ces choses, je serais probablement plus loin vers zéro bogue, mais cela n'aurait pas de sens commercial.
Je crée des outils internes qu'une grande partie de notre infrastructure utilise. 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 demander aux gens de consacrer ce genre de temps à un seul travail. Les choses pourraient être différentes si je créais le logiciel pour contrôler une machine à rayons X, des moteurs à réaction, etc. Aucune vie n'est en jeu si mon logiciel tombe en panne, nous ne nous engageons donc pas dans ce niveau d'assurance.
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 et très coûteuses.
Je pense qu'une bonne première étape pour devenir un programmeur "zéro bug" est de changer votre attitude envers les bugs. Au lieu de dire des choses "elles se produisent", "améliorez le contrôle qualité et les testeurs" ou "les développeurs craignent les tests", dites:
Les bugs 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 bugs tomberont rapidement. Dans votre recherche pour trouver des moyens d'éliminer les bogues, vous rencontrerez un développement piloté par les tests. Vous trouverez de nombreux livres, articles de blog et personnes offrant des conseils gratuits sur de meilleures techniques. Vous verrez l'importance d'améliorer vos compétences grâce à pratique (comme coder des katas ou essayer de nouvelles choses à la maison). Vous commencerez à mieux performer au travail parce que vous commencerez à travailler sur votre métier à la maison. Et, espérons-le, une fois que vous verrez qu'il est possible d'écrire un bon logiciel , votre passion pour votre métier grandira.
Dans un sens, votre patron a raison. Il est possible d'écrire un logiciel qui approche de zéro bogue.
Mais le problème est que le coût de l'écriture (presque) de programmes 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 saine.
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 de tests d'unité, de régression et de système complets pour tester dans tous les sens les bogues. (Et cela ne suffit pas en soi.)
Demandez à beaucoup personnes de revoir 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 qu'il faut pour tout faire.
J'ai atteint le statut "zéro bug". Je dis à mes utilisateurs que c'est une fonctionnalité non documentée, ou qu'ils demandent une nouvelle fonctionnalité et donc c'est une amélioration. Si aucune de ces réponses n'est acceptée, je leur dis simplement qu'ils n'ont pas compris leurs propres exigences. Ainsi, il n'y a pas de bugs. Les programmeurs sont parfaits.
Voici les étapes pour créer un programme sans bug:
- Ne commencez jamais à coder à moins que vous ayez des SPÉCIFICATIONS NON AMBIGUES pour votre fonctionnalité.
- NE TESTEZ PAS ou si vous ne vous FIEZ PAS AUX TESTS pour détecter les défauts du logiciel.
- Appliquez tous les commentaires des 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 complètement tous les composants défectueux dès que des défauts sont détectés. Mettez à jour vos listes de contrôle et formez à nouveau vos développeurs afin qu'ils ne commettent plus d'erreurs de ce genre.
Les tests ne peuvent que prouver que vous avez des bogues, mais il est généralement inutile de prouver le contraire. En ce qui concerne les commentaires - si vous avez une machine à fabriquer des pièces qui fabrique des pièces et que chaque pièce de 10s en moyenne a un défaut. Vous pouvez prendre cette pièce, l'aplatir et la réinsérer dans la machine. la pièce qui a fait ce blanc recyclé ne sera pas aussi bonne, mais peut-être acceptable. chaque pièce de 100s devra être re-tamponnée 2 fois et ainsi de suite. Serait-il plus facile de réparer la machine?
Malheureusement, les gens ne sont pas des machines. Pour faire un bon programmeur sans défaut, vous devez investir beaucoup de temps, vous entraîner et répéter 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. L'économie du développement logiciel y est également défavorable - investiriez-vous 2 ans dans la formation d'un programmeur qui peut faire moins de défauts juste pour le voir passer à un autre employeur? Vous pouvez acheter une machine qui fait des pièces parfaites, ou embaucher 10 singes de code supplémentaires pour créer un tas de tests au même coût. Vous pouvez percevoir ce processus exhaustif comme votre "machine", votre atout - investir dans une formation approfondie d'excellents développeurs ne rapporte pas.
Bientôt, vous apprendrez à développer des logiciels de qualité acceptable, mais vous ne serez probablement jamais un sans défaut pour la simple raison qu'il n'y a pas de marché pour un développeur qui fabrique du code parfait car il est lent.
Si nous supposons que les grands éditeurs de logiciels savent comment obtenir des développeurs de premier ordre (comme dans programmeur zéro bogues ) nous pouvons déduire que le logiciel de Microsoft doit être sans bugs. Pourtant, nous savons que c'est loin de la vérité.
Ils développent leur logiciel et lorsqu'ils atteignent un certain niveau de bogues de faible priorité, ils libèrent simplement le produit et les résolvent plus tard.
À moins que vous ne développiez quelque chose de plus complexe qu'une simple calculatrice, il n'est pas possible d'éviter tous les bugs ensemble. Enfer même la NASA a également une redondance sur leurs véhicules et leurs bugs. Bien qu'ils aient des tests beaucoup plus rigoureux pour éviter les pannes catastrophiques. Mais néanmoins, même ils ont des bogues dans leur logiciel.
Les bugs sont inévitables tout comme la nature humaine à se tromper.
N'avoir aucun bogue, c'est comme avoir un système 100% sécurisé. Si un système est 100% sécurisé, il n'est certainement plus utile (il se trouve probablement à l'intérieur de tonnes et de tonnes de béton et n'est pas du tout connecté à l'extérieur. Ni câblé ni sans fil. Donc, tout comme il n'y a pas de système parfaitement sécurisé , il n'y a pas de système complexe sans bug.
Programme défensivement: http://en.wikipedia.org/wiki/Defensive_programming
Si quelqu'un suit les conventions de la programmation défensive, les modifications seront facilement traçables. Combinez cela avec des rapports de bogues 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 corriger très efficacement les bogues qui surviennent.
Cela pourrait-il être le résultat d'un malentendu sur une méthodologie bonne, et pas seulement sur la tête d'os générique?
Ce que je veux dire, c'est qu'il est possible que votre patron ait entendu parler de "méthodologie zéro défaut" (voir la section n ° 5), et n'a pas pris la peine de comprendre ce que cela signifiait?
Bien sûr, il n'est pas pratique pour la direction de reporter le développement de nouvelles fonctionnalités, en faveur de bugs que vous n'aurait pas dû mettre en place ...
Et bien sûr, cela menace son bonus, donc bien sûr vous n'en obtiendrez pas car "les bons programmeurs n'ont pas de bugs" ...
C'est bien de faire des bugs, tant que vous pouvez trouver eux et corriger eux (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 toutes les combinaisons entrée/variable.
Votre patron semble être l'un de ceux qui "ne comprennent pas ce qui est si difficile à programmer, car il ne fait que taper"