Pouvez-vous créer un bug volontairement ?

Nous, développeurs, rencontrons régulièrement des bugs , cela fait simplement partie de notre travail. Par conséquent, à première vue, la question « Peut-on créer un bug volontairement ? » peut paraître banal - "Oui, bien sûr, je peux écrire un bug." Pourtant, à bien y réfléchir, tout ne semble plus si évident.

Le fait est que le bug n'est pas la même chose qu'un code cassé . Un bug est une erreur, une faille dans un système généralement

programme de travail.

Quel est le problème?

Le monde est connu pour être bien décrit par des formules mathématiques. Et les formules sont en réalité des algorithmes. Par conséquent, si nous étions capables de décrire mathématiquement un phénomène, alors corriger la formule résultante pour qu'elle ne donne que parfois un résultat erroné n'est pas une tâche triviale. Néanmoins, il n’est pas temps de désespérer. Les conditions aux limites peuvent venir nous aider ici. Nous les avons tous vus if index == 0 {…} else if index == n-1 {…} . Il y a toujours quelque chose qui ne va pas avec les limites 🤷‍♀️. Notons donc la première idée pour créer un bug - ignorer les cas extrêmes .

En général, parcourir les tableaux est un réservoir de bugs potentiels. Et le plus courant d'entre eux est l'index hors limites . Si vous n’êtes jamais tombé sur une telle chose, vous n’avez jamais codé. Malheureusement, ce bug est si populaire que les gens ont commencé à écrire des wrappers sécurisés pour les tableaux, quelque chose comme array[safe: index] . Ainsi, aujourd’hui, vos collègues n’approuveront pratiquement aucun code sans cette chose. Vous pouvez essayer, mais c'est peu probable…

Les bogues courants incluent le débordement de pile . Un algorithme récursif peut se reproduire à l’infini lorsqu’il n’y a pas de condition de sortie. La récursivité semble facultative ici - écrivez while true et vous avez terminé. Mais là encore, la popularité du bug joue en notre défaveur. Les développeurs sont bien conscients des problèmes potentiels des boucles sans fin, et leurs yeux remarqueront certainement quelque chose comme ça lors de la révision du code 👮

Pour continuer à pousser votre plan insidieux en production, essayez d'utiliser une variable globale pour les conditions de sortie et modifiez-la discrètement de l'extérieur .

 var coditionCounter = 0; class A { func foo() { while coditionCounter < 10 { coditionCounter++; B.boo(); } } } class B { func boo() { coditionCounter--; } }

Conseils généraux

C'est drôle que même ChatGPT refuse d'aider lorsqu'il s'agit d'écrire des bugs. Peut-être que j'ai juste besoin d'un abonnement premium… 🤔

Du bon côté, l'IA propose un ensemble de règles générales qui contribuent à écrire du code sans bugs : coder par petits incréments, suivre les normes de codage, écrire des tests unitaires et bla-bla-bla. Nous pouvons essayer de faire l'inverse : écrire du code spaghetti et oublier SOLID. Cependant, de cette façon, nous perdons le contrôle de tout le code que nous écrivons. Au lieu d’une arme élégante et précise, nous obtenons un chaos ingérable qui va vaincre notre programme.

Lors de la résolution du problème de la création d'un bug, il convient de déterminer les sous-tâches. Tout d’abord, nous devons proposer des cas extrêmes rares. Deuxièmement, nous devons déguiser le bug en code normal afin qu'il passe la révision du code. Troisièmement, nous devons détourner l’attention du département QA. Quatrièmement, ne vous laissez pas prendre tout de suite. Mais c'est déjà facultatif.

Mon conseil général est le suivant (et vous partagez le vôtre dans les commentaires) :

• Manipuler le niveau d'accès . Pour revenir en arrière, modifiez les valeurs des paramètres importants depuis les endroits les plus inattendus. Faites cela à travers plusieurs cours comme si vous étiez un VPN.

• Implémentez une logique inattendue dans la classe enfant. Bref, cassez le principe L dans SOLID .

   class A { func decrease() { x--; } } class B: A { override func decrease() { x++; } }

• Cachez vos changements insidieux dans des fonctions plus importantes. Plus il y a de files d'attente, mieux c'est - perdez-vous dans la foule.

• Utilisez le même principe dans les pull request. Dans un petit PR, la probabilité d'être remarqué est plus élevée.

• Essayez de diviser le bogue en plusieurs parties et de les placer dans différentes demandes d'extraction . Si possible, également à différents évaluateurs.

• Trouvez les faiblesses de votre assurance qualité et gagnez sa confiance. Ou distrayez-les avec des conversations pendant le contrôle.

Au fait, avez-vous entendu parler de Heisenbug ? Il s'agit d'un bug qui disparaît ou change de comportement lors de la recherche/ débogage . Comme le chat de Schrödinger. Parfait si le problème de résolution ne vous sera pas attribué.

Tu peux

Croyez en vous! L'histoire connaît des exemples de bugs admis en production dans des entreprises très sérieuses.

Ariane 5 Vol 501 : L'un des bugs logiciels les plus coûteux s'est produit en 1996 lorsque la fusée Ariane 5, transportant la mission Cluster, a explosé 40 secondes seulement après le décollage. L'échec est dû à un bug logiciel dans le système de guidage de la fusée.

Mars Climate Orbiter de la NASA : En 1999, la NASA a perdu le Mars Climate Orbiter en raison d'une erreur logicielle. Le logiciel utilisait des unités impériales (livre-seconde) au lieu d'unités métriques (newton-secondes), provoquant l'incendie du vaisseau spatial dans l'atmosphère martienne.

De plus, certains bugs peuvent devenir des fonctionnalités, comme un saut de mur dans Mario ou le comportement du Mahatma Gandh dans Civilization … probablement.

Développer un bug, c'est la capacité de réfléchir à votre algorithme et d'anticiper minutieusement les problèmes possibles. Donc, même si vous n’avez aucune raison de laisser un bug dans le code, cela vaut quand même la peine d’y réfléchir.