un petit bug informatique c'est pas la fin du monde quelques clients énervés à gérer au pire des cas une petite paire d'argent mais il y a des domaines où une simple erreur aussi minuscule soit-elle peut avoir des conséquences dramatiques ça par exemple c'est Arian 5 c'était Arian 5 pas de panique il y avait personne à bord mais tu viens de voir 500 millions de dollars partir en fumé à cause d'un bug informatique ouais j'aimerais pas être ce dev là surtout que c'était une erreur débile en informatique on évite toujours de réinventer la roue si un truc marche et a déjà été codé on va le reprendre et rien changer c'est ce qu'ils ont fait chez l'Agence spatiale européenne en reprenant le logiciel de guidage d'Arian 4 pour le mettre dans Arian 5 dans ce logiciel la variable allouée à l'accélération horizontale est codée sur 8 bits et sur Arian 4 cette valeur n'allait jamais au-delà de 64 et pouvait donc être stocké dans notre variable par contre Arian 5 bien plus puissante dépasser les 64 et du coup quand le logiciel tentait de récupérer la valeur celle-ci était trop grosse pour être stocké comme ça on a un overflow et par effet domino donc ouais il y a bien des applications dans lesquelles tu veux un code avec zéro bug alors comment faire bah déjà est-ce que c'est possible donne-moi 5 secondes et voilà pas un bug là-dedans tu sûr ça tourne sur un ordi ordi sensible au rayon cosmique une particule de haute énergie venue de l'espace qui peut par exemple modifier la valeur d'un bit pile au mauvais moment ok j'abuse un peu n'empêche que ça arrive mais oui disons qu'il n'y a pas de bug sauf que tu coderas jamais un programme aussi simple un programme informatique ce sera toujours un composant qui dépend d'un autre composant qui dépend d'un autre composant qui et plus tu en a plus la probabilité d'erreur augmente on retrouve cette idée dans cette analyse de distra un des gigaboss de l'informatique qui a créé un des algorithmes les plus célèbres si p est la probabilité qu'un composant soit correct la probabilité que tout ton programme fait de N composant soit correct et P puissance n donc si tu es sûr à 90 % qu'un composant est entièrement correct ce qui est plutôt optimiste avec seulement 10 comme ça tu passes à 35 % de chance d'avoir aucun bug c'est pas ouf ce qu'on fait en général c'est un tas d'unit test chaque fature du programme est testé individuellement chaque bug trouvé aura un nouveau unit test et comme ça dès que tu rajoutes une fiture dès que tu changes ton code tu peux lancer les tests et vérifier qu'il a pas un effet papillon qui fait que ce que tu as rajouté détruise une autre fiture car ouais les bugs c'est très fourbe c'est pas mal mais c test permettre de prouver la présence de bug mais pas leur absence et tu pourras jamais trouver leur absence c'est impossible et c'est prouvé par le théorème de Rice duquel on peut déduire qu'on ne peut pas écrire un programme qui prouve l'absence de bug dans du code alors s'il est presque impossible d'avoir aucun bug comment être serein à l'idée qu'une vie dépendent de ton code bah la NASA ils ont 10 règles très strictes à respecter quand ils programment aujourd'hui on va analyser les 10 règles pour un logiciel fiable écrit par gerérard olzman du laboratoire NASA il y a sûrement quelques trucs à entirer pour nous même si un bug n'est pas aussi dangereux dans nos cas mais ça peut quand même être très embarrassant c'est vrai que quand tu as un site la moindre erreur peut faire du mal à ta réputation c'est beaucoup de pression sur tes épaules sauf si tu utilises hostinger avec leur créateur de site web tu as même pas besoin de coder le site tuas juste à le décrire à uneia et elle s'occupe de tout 30 secondes et paf tu as un site ultra propre et si tu veux faire quoi que ce soit manuellement c'est un jeu d'enfants également leur outil est ultra intuitif tu peux aussi utiliser leurs nombreux outils il a pour le faire à ta place écrire du texte pour toi générer des photos et tout un tas d'autres trucs c'est un gain de temps considérable mais ça s'arrête pas là non seulement c'est accessible pour seulement 3 € par mois et en plus tuas un nom de domaine gratuit une assistance en français 24 he/ 24 7 jours sur 7 et tu peux héberger jusqu'à 100 sit web pour un petit euro de plus tu peux même créer un site e-commerce avec 0 % de frais de transaction et plus de 20 méthodes de paiement ça te donne aussi accès aux outils Ia et un CDN gratuit et t'inquiète pas c'est du solide trafi imité SSL illimité site web ultra rapide bref tu peux relâcher la pression sur tes épaules tu es entre de bonnes mains alors je t'invite à utiliser le lien en description et à prendre un abonnement de 12 mois ou plus ce qui te permettra d'avoir le meilleur prix et rendra possible l'utilisation de mon code promo v2f pour avoir 10 % supplémentaires ok 10 règles on commence donc avec la première éviter les structures de codes complexes comme les goto set jump long jump et la récursivité le mieux pour éviter les bugs c'est de pouvoir analyser facilement ton ton code le problème c'est qu'avec ces instructions dans ton code bah ça devient beaucoup plus dur vu que ces instructions permettent pour faire cours de dire à ton programme ok attends reviens à la ligne 6 et maintenant continue et hop en fait non restore l'environnement qu'on avait à la ligne 2 bah tu le vois c'est un bordel à suivre tu veux que ton code soit linéaire le plus lisible possible c'est un peu le même problème avec la récursion c'est-à-dire une fonction qui s'appelle elle-même jusqu'à atteindre un certain objectif c'est plus imprévisible et sur des systèmes embarqués avec peu de mémoire tu peut vite avoir une erreur Stack Overflow quand la fonction s'est appelée elle-même trop de fois et qu'on a plus de place pour stocker tous ces appels et il faut dire que créer une boucle infiniie sans faire exprès avec de la récursion ça arrive beaucoup plus souvent qu'avec une simple boucle alors prenons pas de risque en parlant de boucle infinie règle numéro 2 les boucles doivent toujours avoir une limite fixe si par exemple tu veux qu'un bout de code tourne tant qu'une condition est vraie et qu'au final la condition est tout le temps vrai c'est embêtant alors chez la NASA il préfère toujours avoir une limite fixe un nombre d'itérration à pas excéder sinon on sort de la boucle quoi qu'il arrive ça vite ce problème règle 3 éviter d'allouer de la mémoire sur la hip quand tu codes tes variables tes fonctions tout ça doit être sauvegardé en mémoire et deux choix s'offrent à toi la hip ou le stack la mémoire stack est gérée par le compilateur qui a été codé et vérifié par tout un tas de développeurs talentueux et ce depuis probablement avant même que tu sois né la mémoire hip est gérée par toiut faut vraiment que j'argumente plus là règle 4 toutes les fonctions doivent faire moins de 60 lignes une fonction devrait faire une seule chose et pour faire une seule chose bah tu as pas besoin de 300 lignes de code règle 5 utiliser au moins deux assertions par fonction l'idée c'est simple plus tu fais de vérification plus tu réduis le risque d'erreur bon par contre pourquoi de et pas plus bah j'ai pas trouvé pourquoi j'imagine parce que c'est toujours une bonne idée de vérifier les variables données à ta fonction par exemple si tu veux faire un calcul mais quand te file une lettre bah ça va être compliqué donc vaut mieux vérifier et c'est une bonne idée aussi de vérifier si le résultat final qui sort de ta fonction est correcte également par exemple si tu veux faire un calcul d'une température et que tu as moins 3 millions il y a probablement un petit problème règle numéro 6 déclarer les variables dans le plus petit scope possible quand tu codes tu peux définir une variable de telle sorte que seule la fonction où elle se trouve puisse l'utiliser et la modifier mais tu peux aussi la mettre à l'extérieur comme ça toutes tes fonctions peuvent se la partager on veut éviter ça simplement parce que c'est plus dur à débugger encore une fois si j'ai un problème avec cette variable et qu'elle est accessible uniquement pour cette fonction bah je sais où regarder si elle est accessible par plein de fonctions et ben j'en sais rien règle 7 vérifier la valeur retourné par ta fonction ainsi que ces paramètres j'en ai déjà parlé pour la règle numéro 5 je vous avoue que je trouve qu'on aurait pu fusionner les deux ensemble mais enfin bref du coup passons règle 8 utiliser le préprocesseur avec parciimony un préprocesseur c'est un programme qui va transformer ton code source avant qu'on l'exécute par exemple quand tu fais un appel à un autre fichier de code il va rajouter le le code de ce fichier par-dessus ton code pour pouvoir l'utiliser et ça bah il y a pas de souci ce que la NASA déteste par contre c'est quand on utilise le préprocesseur pour faire des compilations avec des conditions ça permet d'éviter les confusions plus tuas de conditions comme ça plus ça va être dur de les vérifier pour n conditions ajouté tu as deux puissan n possibilités à tester règle numéro 9 éviter les pointeurs c'est quoi déjà un pointeur imaginons que tu as une variable avec un nombre entier un pointeur permet d'avoir l'emplacement de cette variable dans ta mémoire bon ça peut être utile mais les outils qui analysent ton code automatiquement ont beaucoup de mal à gérer ses pointeurs proprement donc il risque de louper des bugs donc on veut éviter ça règle 10 compiler avec tous les warnings du compilateur bah celuilà il s'explique tout seul on veut autant d'infos que possible écoute si tu testes ton code avec plein d'unit test et que tu appliques ces 10 règles je pense que tu peux envoyer ton CV à la NASA bah alors tuattends quoi