Bonjour et bienvenue.
Dans cet exposé, j'aimerais parler du débogage.
Il s'agit d'un concept très important que vous devez comprendre, en particulier certains des outils et certaines
des méthodes que vous pouvez utiliser pour trouver et corriger les bogues.
Le débogage est donc le processus qui consiste à trouver et à corriger les erreurs dans un programme.
Il s'agit généralement d'erreurs de logique.
Je vais vous expliquer la différence entre les erreurs de logique et de syntaxe, mais il peut également s'agir d'erreurs de
syntaxe du compilateur.
Il s'agit de l'ensemble du processus pour les erreurs de syntaxe.
Le débogage consiste à comprendre ce que le compilateur vous dit.
Il faut toujours se concentrer sur la résolution du premier problème détecté.
Je vais passer en revue quelques-unes des erreurs et des avertissements les plus courants du compilateur, mais l'une
des choses qu'il faut toujours savoir à propos du compilateur, c'est qu'il peut vous donner un certain nombre
d'erreurs.
Il faut toujours se concentrer sur la première erreur, car elle peut en entraîner d'autres.
Il peut donc être très trompeur de voir cinq erreurs dans un programme, alors que le compilateur vous dit qu'il n'y a peut-être qu'une seule
erreur et que cette première erreur peut être à l'origine des autres.
Il est donc important de toujours considérer la première erreur et de la corriger en premier.
Dans cet exemple très simpliste, nous avons de multiples erreurs dans ce code.
Nous n'avons pas de.
Nous n'avons pas d'accolade gauche ni d'accolade curviligne.
Nous n'avons pas de point-virgule.
Nous renvoyons une chaîne de caractères.
Ainsi, lorsque nous sauvegardons ceci et que nous allons le compiler et que vous voyez des erreurs
rouges, lorsque nous allons le compiler, il nous dit en fait que nous avons trois erreurs.
Il ne faut jamais se contenter de sélectionner la dernière erreur de la ligne sept, même si, dans ce cas, il s'agit d'une erreur réelle.
Il faut toujours se contenter de corriger la première erreur.
Vous voyez donc la première erreur listée ici et vous corrigez cette première erreur, puis vous recompilez et vous l'exécutez à nouveau.
Mais la raison pour laquelle il faut faire cela est uniquement de corriger l'erreur de premier niveau, car cette erreur peut causer d'autres
problèmes.
Le débogage et le processus de recherche et de correction des bogues peuvent être très complexes, depuis la recherche
de simples erreurs jusqu'à la collecte de grandes quantités de données à des fins d'analyse.
Tout dépend.
Parfois, vous ne disposez d'aucune information, à l'exception de l'enregistrement, et dans ce cas, vous devez
analyser les choses.
Il arrive parfois que des bogues ne soient pas reproductibles.
Il est impossible de le reproduire, car il est très rare.
C'est généralement à ce moment-là qu'il faut analyser les journaux ou une autre variante.
La capacité de débogage d'un programmeur est une compétence essentielle.
Il s'agit en fait d'une compétence en matière de résolution de problèmes qui peut vous faire gagner énormément de temps et d'argent.
Il s'agit donc d'une compétence importante à acquérir.
C'est une compétence importante à développer.
Il faut de la pratique.
Vous n'allez pas vous contenter d'en faire l'expérience, cela ne viendra pas tout seul.
Il existe certaines techniques et méthodes que vous pouvez appliquer pour améliorer vos compétences en
matière de débogage.
Je connais un certain nombre de développeurs qui sont vraiment doués pour écrire des logiciels et du code.
Ils comprennent très bien le langage, mais leurs compétences en matière de débogage sont très faibles.
Ils peuvent être confrontés à un bogue et leur premier réflexe pour résoudre ce bogue n'est pas du tout le bon.
Encore une fois, cela se fait avec la pratique.
Vous deviendrez de plus en plus doué pour le débogage et vous comprendrez comment trouver et résoudre les problèmes, mais
c'est aussi quelque chose que vous devez apprendre.
La phase de maintenance est la phase la plus coûteuse du cycle de vie du logiciel.
La phase de maintenance intervient après la mise sur le marché de votre produit et vous devez maintenant en assurer la maintenance.
La maintenance consiste à corriger les bogues éventuels et à ajouter de nouvelles fonctionnalités.
Ainsi, par exemple, lorsque Windows sort un nouveau système d'exploitation tel que Windows 10, la production de ce logiciel
n'est pas terminée.
Il restera sur le terrain pendant probablement dix ans.
Il incombe toujours à Microsoft de corriger les bogues qui surviennent ou qui sont découverts pour ce logiciel.
C'est la raison pour laquelle ils proposent des mises à jour automatiques et font ce genre de choses.
Ils remarqueront également que le système d'exploitation propose de nouvelles fonctionnalités en fonction de l'évolution
du marché et de la technologie.
L'entretien est donc très important.
Il est donc très important de trouver et de corriger les bogues.
Il faut cependant comprendre que les bogues sont inévitables.
Tous les logiciels ont des bogues.
Personne ne peut écrire un code parfait et il ne s'agit même pas nécessairement d'écrire un code parfait.
C'est juste que les choses changent avec le temps.
Cela peut donc également entraîner des bogues.
Il faut comprendre que ce n'est pas parce qu'un logiciel a des bogues qu'il est mal écrit.
C'est en quelque sorte inévitable.
Il n'y a donc pas de mal à avoir des bogues, mais lorsque vous les trouvez et les corrigez, c'est encore mieux parce que vous avez l'impression
d'avoir accompli quelque chose.
Problèmes courants.
Et nous allons parler plus en détail des problèmes spécifiques liés à la vue.
Mais les problèmes les plus fréquents lorsque vous essayez de déboguer sont les erreurs de logique.
Les erreurs de logique ont à voir avec le contraire du type d'erreurs de syntaxe que votre code compile réellement.
Il fonctionne, mais il ne fait pas ce qu'il est censé faire.
Il y a donc une sorte de logique ou de fonctionnalité prévue qui est incorrecte.
Vous avez peut-être une instruction IF et vous vous lancez dans cette instruction si la condition n'est pas la bonne.
Vous avez peut-être une boucle qui ne s'exécute pas le bon nombre de fois ou qui n'est pas triée correctement.
La fonctionnalité est cassée, mais le compilateur dit : "Hé, tout a l'air bien".
Voici un exemple d'erreur de logique.
Une erreur de logique se produit lorsque la syntaxe est correcte, mais que les résultats souhaités ne sont pas corrects en raison d'un problème
de logique.
Ainsi, dans ce code, vous voyez que la boucle for a un point-virgule à la fin, ce qui est correct d'un point de vue syntaxique.
Mais vous vous attendez à ce que cette boucle for s'exécute cinq fois.
Mais ce n'est pas le cas.
Il n'y aura qu'un seul passage.
Donc si nous disons build et que nous construisons ce projet, nous voyons un avertissement, ce qui est bien et vous devriez toujours corriger tous vos avertissements.
Mais il a été compilé avec succès.
Ainsi, lorsque nous exécuterons ce projet, vous remarquerez qu'il ne s'exécute qu'une seule fois et qu'il n'imprime
Hello World qu'une seule fois.
Il s'agit donc d'un exemple d'erreur de logique.
Les erreurs de syntaxe sont directement liées au compilateur.
Il s'agit de choses qui ne respectent pas les règles de la langue.
Il n'y a pas de point-virgule à la fin d'une déclaration.
Vous n'avez pas de fin, n'est-ce pas ?
Parenthèses à gauche, parenthèses.
Il manque un crochet.
Vous n'utilisez pas le bon mot-clé, etc.
Les erreurs de syntaxe sont généralement causées par le compilateur. Les erreurs logiques seront causées par le programmeur
pendant la phase de test.
La corruption de la mémoire est également un problème courant, en particulier en C.
Si vous ne libérez pas correctement votre mémoire après l'avoir allouée, vous pouvez
avoir des références pendantes et vous pouvez également avoir des problèmes de mémoire liés à la mémoire qui n'est pas utilisée.
Il peut y avoir des fuites de mémoire.
Voici un exemple d'erreur de mémoire.
Dans ce code particulier, nous avons une fuite de mémoire, nous n'avons donc pas encore parlé des pointeurs.
Nous n'avons pas encore parlé de l'allocation dynamique de la mémoire.
Mais en C, vous pouvez allouer de la mémoire pendant que votre programme est en cours d'exécution.
Vous pouvez utiliser la fonction malloc.
Et donc ici, nous marquons, nous allouons de la mémoire, mais nous ne la libérons jamais.
Nous pouvons donc construire ce code et l'exécuter et tout va bien, mais nous ne libérons pas réellement cette
erreur.
Ainsi, pour corriger cette erreur de mémoire, il faudrait dire free, puis free
et X pour libérer ce pointeur.
Mais chaque fois que vous allouez de la mémoire, vous ne la libérez pas.
Il s'agit d'une fuite de mémoire.
Autre exemple : si nous n'allouons pas la mémoire, si nous créons un pointeur et que nous essayons de l'assigner,
nous aurons une corruption de la mémoire parce que cette mémoire n'est pas allouée et que nous essayons
d'y assigner une valeur.
Voilà donc un petit aperçu de quelques exemples concernant la mémoire, la corruption, les performances et l'évolutivité.
Il peut s'agir d'un problème où votre fonctionnalité est prévue telle quelle et votre code est syntaxiquement correct,
mais il n'est pas très efficace ou vous n'avez pas le matériel pour le supporter.
Par conséquent, si vous utilisez un serveur et que vous n'avez pas assez de matériel pour répondre à toutes les demandes,
il fonctionnera très, très lentement.
Ou si vous avez écrit votre programme pour qu'il fonctionne avec dix utilisateurs, mais que lorsqu'il y a beaucoup d'utilisateurs,
il n'est peut-être pas aussi rapide parce que la base de données s'embourbe ou autre.
Le code fonctionne, mais il n'est pas conçu correctement pour gérer un très grand nombre d'utilisateurs
ou autre.
Manque de cohésion.
Il peut s'agir d'un problème dans votre code qui réduit la qualité, lié au fait que votre code en fait trop ou qu'une
fonction en fait trop.
Il ne s'agit pas d'un objectif unique ou même d'une application qui a trop de fonctionnalités, qui a des fonctions
qui ne sont jamais utilisées, et qui nécessiterait donc probablement une refonte.
Voici un exemple de programme qui ne serait pas modularisé, qui ne serait pas cohésif.
Vous avez une grande fonction qui fait beaucoup trop de choses, des centaines de lignes de code, des milliers de lignes
de code.
Vous souhaitez décomposer une fonction en fonctions d'aide, en modules distincts.
Cela rend votre programme beaucoup plus cohérent et plus facile à maintenir.
Ainsi, au lieu d'avoir une grosse méthode principale qui fait l'initialisation, la lecture de l'entrée, la recherche de certains,
la recherche de la différence, la recherche du produit, la recherche du quotient, vous pouvez créer tout ce code et le mettre dans
des modules d'aide et séparer le code, de sorte que la séparation peut aider à trouver et à corriger vos bogues beaucoup plus facilement.
La cohésion est toujours importante en C et elle est généralement résolue lorsque la cohésion est élevée en fournissant des
méthodes d'aide.
Accouplement serré.
Cela est également lié à la qualité du code.
C'est ici qu'il y a le plus de dépendances.
Le couplage est différent de la cohésion.
La cohésion est votre seul objectif.
Le couplage consiste à créer des dépendances entre des fonctions ou des objets.
Nous avons parlé de couplage, de variables globales.
Si une variable globale est utilisée dans un grand nombre de fonctions différentes, elle peut créer des dépendances
entre ces fonctions.
Ainsi, lorsque vous écrivez du code et que vous écrivez du code de haute qualité, vous devez
viser une cohésion très élevée et un couplage très faible.
Le processus de débogage.
La première chose à faire avant de trouver et de corriger une erreur est de comprendre
le problème.
Il ne faut pas se contenter de plonger et de commencer à regarder le code, il faut s'asseoir avec le testeur, comprendre
les exigences, comprendre ce qui se passe.
Car si vous ne comprenez pas ce qui se passe, vous ne pourrez même pas le faire.
Vous ne devriez même pas essayer de le résoudre.
Une fois que vous avez compris le bogue, essayez de le reproduire, car la reproduction du bogue peut vous aider à recueillir davantage
d'informations.
Il n'est pas toujours possible de reproduire les bogues, car ils peuvent se produire dans des circonstances très rares.
Ainsi, par exemple, les bogues qui présentent des conditions de course ou même une corruption de la mémoire ne peuvent se produire que dans
des cas d'utilisation très spécifiques et il peut s'agir de problèmes intermittents.
Est-ce le cas ?
Et vous ne pouvez pas le reproduire.
Il va devenir de plus en plus difficile à déboguer.
Si vous êtes en mesure de le reproduire, vous pouvez généralement recueillir suffisamment d'informations pour y remédier.
La plupart des problèmes peuvent être résolus.
Vous pouvez également rencontrer des problèmes d'impossibilité de reproduire un problème dans le cas d'un environnement multithread,
de processus parallèles ou de problèmes de threading.
Ceux-ci sont également très difficiles à déboguer, mais il faut absolument essayer de les
reproduire une fois que l'on a compris le problème, c'est-à-dire une fois que l'on est capable de le
reproduire, si ce n'est pas le cas, il faut essayer de diviser pour mieux régner.
Il faut essayer d'isoler le bogue, de simplifier le problème, car le fait de pouvoir réduire le bogue va vous donner des informations,
mais cela ne vous dira pas nécessairement dans quelle partie du code se trouve le bogue.
Pour tenter de simplifier le problème, on peut donc supprimer certaines parties du scénario de test original afin de
ne pas tester trop de choses.
Vous pouvez isoler le problème encore plus petit en disant : "Oh, cela ne se produit que dans cette situation spécifique".
Vous pouvez également commenter le code.
Nous avons parlé des fonctions qui n'ont que des stubs et qui n'ont pas d'implémentation.
Parfois, cette méthode est utilisée dans le cadre de tests afin de limiter l'ensemble des problèmes.
De plus, si vous commentez le code, vous aurez moins de code où le bogue peut réellement se produire.
Ainsi, lorsque vous commentez du code ou que vous annulez des modifications, le bogue peut disparaître et si le bogue disparaît, cela vous
indique que le code que vous avez commenté peut avoir été à l'origine du bogue.
Ce que vous voulez essentiellement faire, c'est transformer un grand programme en un grand nombre de petits programmes, soit
en les testant, soit en les commentant.
Une autre technique courante consiste à effectuer des tests unitaires autour de votre code.
Si un test unitaire échoue, cela peut vous indiquer exactement où se trouve la logique ou le problème dans votre code.
Une fois que vous avez isolé le bogue, cela vous aidera à trouver l'origine du problème dans le code, le code spécifique
qui cause le problème.
Pour ce faire, il faut parfois utiliser des outils de débogage tels qu'un débogueur.
Nous allons parler d'un débogueur en particulier, mais en général, selon l'IDE de développement intégré que vous utilisez,
il y a des débogueurs qui sont fournis avec l'IDE.
Il existe également des débogueurs qui peuvent atterrir de manière autonome.
Le débogueur le plus important que nous allons utiliser pour la programmation en C s'appelle GDB.
Il s'agit du débogueur GNU, un outil agréable qui est en fait un outil graphique dans lequel vous pouvez arrêter
l'exécution de votre programme et ajouter des points d'arrêt.
Ensuite, lorsque vous arrêtez l'exécution, vous pouvez aller ligne par ligne dans votre code et regarder la valeur des variables.
Vous pouvez ainsi voir exactement ce qui se passe dans votre code pendant qu'il s'exécute.
C'est un outil précieux.
C'est juste que c'est tellement utile.
Nous allons passer par le débogueur.
Je vais vous montrer comment ajouter des points d'arrêt.
Je vous montrerai comment mettre en place une surveillance afin que vous puissiez observer les variables au fur et à mesure qu'elles changent, et je vous expliquerai
ensuite le code.
Après avoir identifié l'origine du problème, il faut le résoudre.
Cela demande beaucoup d'expérience et de pratique.
Même si vous avez trouvé l'origine du problème, il se peut que vous ne puissiez pas le résoudre sur la base
de votre seule expérience.
Cela inclut parfois la refonte ou le remaniement d'autres codes qui, en particulier en cas de problèmes d'évolutivité
ou de performance, peuvent devoir être remaniés pour permettre à votre logiciel d'être plus évolutif.
Il n'est donc pas toujours facile de trouver le problème et de le résoudre.
Le problème est parfois encore plus difficile à résoudre, surtout lorsqu'il s'agit de problèmes encore plus difficiles à résoudre,
tels que le threading ou le traitement parallèle.
Mais au fur et à mesure que vous écrivez du code, cela devient de plus en plus facile.
Et enfin, vous devez faire des tests comme des fous.
Testez toujours de nombreuses limites différentes.
Les bons cas, les mauvais cas et les cas intermédiaires pour vérifier que vous avez bien résolu le problème.
Quelques-unes des techniques et des outils disponibles.
Un outil courant et très, très utilisé consiste à utiliser des instructions d'impression.
Vous pouvez utiliser les instructions d'impression pour tracer votre code.
En C, vous pouvez donc utiliser l'instruction print F et la placer à plusieurs lignes de votre code pour indiquer
où vous en êtes.
Cette fonction est également utile, voire très utile, lorsque votre programme se bloque.
Il peut aider à identifier l'endroit où il s'est écrasé.
Lorsque vous ajoutez ces instructions d'impression à votre code, vous pouvez ajouter une sortie dans les instructions
d'impression pour voir la valeur des variables, car la valeur des variables peut affecter l'état et causer des
problèmes logiques.
L'ajout d'instructions d'impression est donc très, très utile.
Il peut montrer le déroulement de l'exécution et aider à isoler l'erreur.
Les débogueurs, comme j'en ai mentionné un dans GDB, permettent de surveiller l'exécution du programme.
Vous pouvez l'arrêter, l'exécuter ligne par ligne, le redémarrer, définir des points d'arrêt, surveiller les variables et la mémoire.
Très, très utile pour diagnostiquer l'origine d'un problème.
Fichiers journaux.
Les fichiers journaux sont également très utiles, en particulier pour les bogues qui ne peuvent pas être recréés.
Vous pouvez les analyser ultérieurement pour savoir exactement ce qui s'est passé au moment où le bogue s'est produit.
Cela signifie que vous devez fournir de bonnes instructions de journalisation dans votre code pour
que cela soit utile.
Vous pouvez donc créer votre propre fichier journal et y écrire pendant l'exécution du programme, de sorte qu'en cas d'erreur, vous
puissiez envoyer ces journaux aux développeurs.
Nous y avons souvent recours chez Xerox, car lorsque nous rencontrons des problèmes, nous ne pouvons pas toujours les reproduire ou ils
peuvent être rencontrés sur le terrain.
Nous devons être en mesure d'accéder à ces journaux pour voir ce qui s'est passé lorsque le bogue s'est produit.
Logiciel de surveillance.
Il existe des logiciels capables de surveiller et d'analyser l'utilisation de la mémoire, les menaces liées au trafic réseau et les informations
sur les objets.
Cela vous permettra de savoir si vous allouez trop de mémoire et si vous ne la supprimez pas.
Si vous disposez d'un outil d'utilisation de la mémoire et du trafic réseau qui peut vous indiquer si vous envoyez trop de paquets ou si votre logiciel est évolutif,
si vous avez une augmentation du trafic réseau et que vous constatez que votre temps de réponse se dégrade, vous pouvez utiliser un outil d'analyse de la mémoire
et du trafic réseau qui peut vous indiquer si vous envoyez trop de paquets ou si votre logiciel est évolutif.
Vous pouvez également surveiller les informations sur les threads et les objets pour le traitement parallèle afin de voir ce qui se passe dans
certains threads et ce qui se passe dans un autre thread.
Cela vous aidera à diagnostiquer tout problème de fil.
Il existe d'autres outils de débogage courants que vous pouvez utiliser pour trouver et corriger vos erreurs.
Vous pouvez utiliser la gestion des exceptions.
De nombreux langages de programmation disposent d'une gestion des exceptions.
Malheureusement, le langage C ne dispose pas d'un gestionnaire d'exception qui permet d'éviter les plantages et de faire beaucoup de choses au moment
de l'exécution.
Cela ne s'applique pas à la vue, mais c'est quand même une bonne chose à comprendre.
Blocs Trycatch, etc.
Analyseurs statiques.
Il existe de nombreux analyseurs statiques disponibles pour les analyseurs statiques C.
Analyser le code source sans l'exécutable.
L'exécution du programme n'est pas nécessaire.
Il examine le code source ligne par ligne.
En analysant le code source, il recherche les problèmes connus.
Il peut donc vérifier la sémantique.
Il peut s'en assurer.
C'est tout.
Il n'y a pas de variables non initialisées si vous allouez de la nouvelle mémoire et que vous la supprimez.
Si vous avez du code mort, c'est-à-dire du code qui n'est pas exécuté, vous pouvez le supprimer.
Il analyse également des éléments tels que les conditions de course et les blocages.
Nous employons quelques analyseurs statiques là où je travaille.
Nous disposons d'un outil appelé Coverity, qui est très populaire, et nous utilisons également un outil de sonar de code, que nous lançons
sur l'ensemble de notre base de référence, sur l'ensemble de nos sources.
Chaque fois que nous introduirons de nouveaux fichiers et un nouveau code, cet outil sera exécuté sur ce code et sera en mesure d'identifier
les problèmes immédiats dans le code en ce qui concerne les variables non initialisées, les fuites de mémoire, etc.
Il n'analyse pas la syntaxe.
C'est à cela que sert le compilateur.
Il existe également un certain nombre de suites de tests qui exécutent un ensemble de tests complets du système de bout en bout que vous
pouvez exécuter sur votre logiciel.
Les tests sont toujours importants, mais si vous pouvez les automatiser d'une manière ou d'une autre pour exécuter certains tests à chaque
fois que vous faites une nouvelle construction, par exemple, cela peut être très utile et cela peut effectivement prévenir
les erreurs, mais cela aide aussi à diagnostiquer les erreurs.
Déboguer le programme après qu'il se soit écrasé.
Nous allons parler de ce que l'on appelle la pile d'appels.
Il s'agit d'un mécanisme très utile, en particulier dans un langage comme le C, où vous avez un plantage et où la seule information
que vous obtenez est quelque chose comme une erreur de segmentation.
Lorsque vous avez ce crash, ce qui arrive souvent, en fonction de la façon dont il s'est produit, un fichier core
est généré et vous pouvez analyser le fichier core pour regarder la pile d'appels et voir exactement où le programme s'est
arrêté.
Il vous indiquera la ligne de code où le programme s'est arrêté.
Nous allons donc nous familiariser avec la pile d'appels.
Quant à l'analyse des fichiers de base, il s'agit d'une technique plus avancée.
Mais en C, un fichier de base peut être généré et vous pouvez l'analyser.
C'est une technique un peu plus avancée, mais c'est une autre façon de déboguer votre logiciel.
Qu'en est-il de la prévention des erreurs ?
Nous savons que le débogage consiste à trouver et à corriger les erreurs, mais si vous pouvez les éviter, c'est encore mieux.
L'une des façons d'éviter les erreurs est d'écrire un code de haute qualité.
Ce n'est pas vraiment l'objectif de beaucoup d'ingénieurs en logiciel.
Beaucoup d'ingénieurs logiciels écrivent le code, et tant qu'il fonctionne, c'est tout
ce qui les préoccupe, ou tant que le résultat est correct, ils considèrent qu'ils ont terminé.
Mais il existe un code de mauvaise qualité et vous ne voulez pas l'écrire.
J'ai démontré certains de ces aspects au cours des conférences, mais il est très important d'utiliser des noms de variables
significatifs.
Ou si vous écrivez un code inefficace dans lequel vous utilisez des boucles peut-être plus que nécessaire, ou si vous utilisez une instruction
if ou si vous n'avez pas besoin de le faire.
Tous ces éléments constituent un code de mauvaise qualité.
Si vous avez une fonction qui fait 100 autres choses et qui n'est pas cohérente, si vous avez 5000 lignes dans une fonction,
si votre code n'est pas organisé de manière modulaire ou si vous avez de nombreuses dépendances entre
les fonctions, encore une fois, tout cela est du code de mauvaise qualité et vous devez vous efforcer de ne pas le faire.
Vous voulez utiliser des techniques où votre programme est organisé.
Il est facile à maintenir, il est très cohésif, il a un faible couplage et vous utilisez des noms de variables significatifs.
Très, très important.
Là encore, c'est très important car la phase d'entretien est très, très coûteuse.
Si vous écrivez un code de mauvaise qualité, il devient beaucoup plus difficile à maintenir.
Il est plus difficile d'isoler les erreurs et d'ajouter de nouvelles fonctionnalités.
Utilisez donc des techniques de haute qualité lorsque vous écrivez votre code.
Tests unitaires.
Les tests unitaires contribuent grandement à prévenir les erreurs.
Les tests unitaires sont généralement exécutés automatiquement lors de la compilation des tests unitaires, ce qui permet d'éviter les régressions.
C'est l'un des facteurs les plus importants.
La régression est le fait d'écrire un nouveau code et d'introduire un bogue sur quelque chose qui fonctionnait auparavant.
Vous avez cassé un ancien code.
Vous ne voulez pas faire cela.
Si un logiciel fonctionne et que quelque chose de nouveau que vous avez fait le casse, vous voulez en être immédiatement informé
et les tests unitaires peuvent vous aider à le faire parce que les tests unitaires s'exécuteront sur l'ancien code et diront : "Hé, cela fonctionnait,
maintenant c'est un échec".
Il permet également de détecter les erreurs dans le nouveau code avant qu'il ne soit livré, car, une fois de plus, il s'exécute après la construction et
vous indique immédiatement si quelque chose ne va pas.
Il existe un concept de développement piloté par les tests qui est en train de devenir très, très populaire.
Dans ce cas, vous écrivez d'abord vos tests, puis vous développez votre code.
L'objectif est que lorsque vous écrivez votre premier test, celui-ci échoue et vous écrivez alors le code pour
le faire passer.
Le TDD présente de nombreux avantages et il s'agit en quelque sorte d'un mode de pensée inversé.
Normalement, lorsqu'on écrit du code, on écrit d'abord le code, puis le test.
Mais avec le TDD, vous avez une autre façon de penser, vous travaillez par petits morceaux et vous
avez tendance à écrire un code très cohérent et vous n'avez pas de code, pas beaucoup de dépendances
parce que devinez quoi ?
Si vous êtes en mesure de tester le code, cela signifie que le code n'a pas autant de dépendances.
Si votre test unitaire est très, très volumineux et que vous mockez toutes ces choses différentes, c'est
généralement un indicateur important que votre code est très, très dépendant d'autres choses.
Ainsi, en employant le TDD, vous êtes obligé d'écrire un code à couplage très lâche qui ne comporte pas de dépendances et vous êtes obligé
de faire en sorte que vos fonctions soient très cohésives.
Le TDD présente de nombreux avantages.
Vous devez également fournir une bonne documentation et planifier correctement.
Ne vous contentez pas de plonger dans le code et de commencer à le mettre en œuvre.
Notez votre projet sur papier.
Utiliser du pseudocode.
C'est vrai.
Planifiez votre code.
Si vous planifiez votre code, si vous comprenez les exigences et si vous avez une bonne conception, vous pouvez
éviter de très nombreuses erreurs.
Et je l'ai mentionné tout au long du cours, mais il est très, très important d'avoir une approche de type
"diviser pour régner", de travailler par petites étapes et de tester constamment après chaque étape, de ne pas écrire 1000 lignes de code
et de dire ensuite, d'accord, compilez et testez.
Ce n'est pas une bonne approche.
Évitez de procéder à trop de changements à la fois.
Lorsque vous apportez des modifications, appliquez-les de manière progressive, ajoutez une modification, puis testez-la minutieusement avant de passer
à l'étape suivante.
Cela permet de réduire toutes sortes de bogues et de limiter le nombre de problèmes.
Ainsi, si vous avez un bogue, vous savez immédiatement où il se trouve dans le code parce que vous venez
de compiler et d'ajouter cette ligne ou ce nombre de lignes.
Encore une fois, je ne saurais trop insister sur l'importance du débogage, de l'écriture d'un code de haute qualité et de la prévention des erreurs.
Ces techniques de résolution de problèmes vous feront gagner beaucoup de temps et feront de vous un bien meilleur
programmeur.
C'est pourquoi, dans les prochains exposés, je voudrais parler de certaines des erreurs courantes que l'on rencontre dans le langage de
programmation c.
Je voudrais également parler un peu de la pile d'appels.
Je vais passer en revue le débogueur et vous présenter les options du menu et la façon dont vous pouvez arrêter et exécuter
les montres, etc.
Je souhaite également vous aider à identifier certaines erreurs de compilation courantes afin que vous sachiez comment interpréter les compilateurs, les avertissements et
les erreurs de compilation.
Qu'est-ce que cela signifie si le compilateur dit cela ?
Que signifie cet avertissement du compilateur ?
Nous vous remercions.