{"id":19685,"date":"2023-07-18T14:17:26","date_gmt":"2023-07-18T14:17:26","guid":{"rendered":"https:\/\/devologyx.io\/le-programmeur-pragmatique\/"},"modified":"2024-10-31T17:44:27","modified_gmt":"2024-10-31T17:44:27","slug":"le-programmeur-pragmatique","status":"publish","type":"post","link":"https:\/\/devologyx.io\/fr\/le-programmeur-pragmatique\/","title":{"rendered":"LE PROGRAMMEUR PRAGMATIQUE"},"content":{"rendered":"\n
\"\"<\/figure>\n\n

Le programmeur pragmatique est un guide habile et pratique qui donne un aper\u00e7u et les bases pour \u00eatre un bon programmeur, en augmentant votre sp\u00e9cialisation et les technicit\u00e9s dans le d\u00e9veloppement moderne de logiciels. Le livre a \u00e9t\u00e9 publi\u00e9 en octobre 1999. Andrew Hunt y aborde les th\u00e8mes de la responsabilit\u00e9 personnelle et du d\u00e9veloppement de carri\u00e8re, ainsi que les techniques architecturales permettant de conserver un code flexible, facile \u00e0 adapter et \u00e0 r\u00e9utiliser. Ce livre vous apprendra \u00e0 lutter contre la pourriture des logiciels, \u00e0 \u00e9viter le pi\u00e8ge de la duplication des connaissances et \u00e0 rendre vos d\u00e9veloppements plus pr\u00e9cis gr\u00e2ce \u00e0 l’automatisation. <\/p>\n\n

COMMENT CE LIVRE NOUS A-T-IL AID\u00c9S ?<\/strong><\/p>\n\n

Ce livre nous a aid\u00e9s \u00e0 comprendre comment les d\u00e9veloppeurs peuvent devenir de meilleurs programmeurs en comprenant les principes fondamentaux n\u00e9cessaires \u00e0 la r\u00e9ussite du d\u00e9veloppement de logiciels. Il montre qu’\u00eatre un bon programmeur ne se r\u00e9sume pas \u00e0 des comp\u00e9tences techniques. Il se concentre sur des sujets pratiques tels que le d\u00e9couplage, l’\u00e9dition de puissance, le d\u00e9bogage et les tests, qui nous aident \u00e0 aider les d\u00e9veloppeurs \u00e0 construire un meilleur code pour nos clients et \u00e0 devenir des consultants et des membres de grandes \u00e9quipes de projet. Le livre nous a aid\u00e9s \u00e0 comprendre comment utiliser notre exp\u00e9rience pour prendre des d\u00e9cisions plus \u00e9clair\u00e9es dans notre vie professionnelle et personnelle. <\/p>\n\n

\"\"<\/figure>\n\n

LE LIVRE EXPLIQU\u00c9 EN MOINS DE 60 SECONDES<\/strong><\/p>\n\n

Le livre utilise des analogies et des histoires courtes pour pr\u00e9senter les m\u00e9thodologies de d\u00e9veloppement et les mises en garde, par exemple la th\u00e9orie des fen\u00eatres bris\u00e9es, l’histoire de la soupe de pierre ou la grenouille bouillante. Il contient \u00e9galement de petits exercices pour mettre en pratique vos comp\u00e9tences en programmation. <\/p>\n\n

Le programmeur pragmatique explique que les d\u00e9fauts des logiciels se manifestent de diff\u00e9rentes mani\u00e8res, depuis les exigences mal comprises jusqu’aux erreurs de codage. Malheureusement, les syst\u00e8mes informatiques modernes sont encore limit\u00e9s \u00e0 faire ce que vous leur dites et non ce que vous voulez qu’ils fassent. <\/p>\n\n

Selon le livre, personne n’\u00e9crit un logiciel parfait. Il est donc \u00e9vident que le d\u00e9bogage occupera une grande partie de votre journ\u00e9e. Le d\u00e9bogage est un sujet sensible et \u00e9motionnel pour de nombreux d\u00e9veloppeurs. <\/p>\n\n

TROIS CITATIONS PRINCIPALES<\/strong><\/p>\n\n

\u00ab\u00a0Les outils amplifient votre talent. Plus vos outils sont performants et mieux vous savez les utiliser, plus vous pouvez \u00eatre productif\u00a0\u00bb.<\/em><\/p>\n\n

\u00ab\u00a0La plus grande de toutes les faiblesses est la peur de para\u00eetre faible.<\/em><\/p>\n\n

\u00ab\u00a0L’\u00e9diteur sera le prolongement de votre main ; les touches chanteront en d\u00e9coupant le texte et la pens\u00e9e.<\/em><\/p>\n\n

R\u00c9SUM\u00c9 DU LIVRE ET NOTES<\/strong><\/p>\n\n

Chapitre 1 : Une philosophie pragmatique<\/strong><\/p>\n\n

    \n
  1. Le chat a mang\u00e9 mon code source<\/strong><\/li>\n<\/ol>\n\n

    Prendre des responsabilit\u00e9s : <\/strong>La responsabilit\u00e9 est quelque chose que vous acceptez activement ; vous vous consacrez \u00e0 garantir que quelque chose est bien ex\u00e9cut\u00e9. Cependant, vous n’avez pas n\u00e9cessairement un contr\u00f4le direct sur tous les aspects. Vous avez le droit de ne pas prendre la responsabilit\u00e9 d’une situation inimaginable ou comportant des risques \u00e9lev\u00e9s. Lorsque vous acceptez la responsabilit\u00e9 d’une situation, ayez l’humilit\u00e9 d’\u00eatre tenu pour responsable. Tout le monde commet des erreurs. Par cons\u00e9quent, lorsque vous faites une erreur de jugement, admettez-la honn\u00eatement et essayez de trouver des solutions. <\/p>\n\n

      \n
    1. Entropie logicielle<\/strong><\/li>\n<\/ol>\n\n

      Le fait qu’une fen\u00eatre cass\u00e9e non r\u00e9par\u00e9e reste dans la maison pendant une longue p\u00e9riode donne aux occupants de la maison un sentiment d’abandon qui finit par provoquer davantage de d\u00e9g\u00e2ts et de ruines. Il en va de m\u00eame pour les logiciels : un mauvais morceau de code peut entra\u00eener d’autres dommages s’il n’est pas r\u00e9par\u00e9 suffisamment t\u00f4t. Par cons\u00e9quent, ne vivez pas avec un code destructeur. Corrigez-le d\u00e8s qu’un bogue est d\u00e9couvert. Prenez des mesures et faites preuve d’initiative afin d’\u00e9viter d’autres dommages et de montrer que vous ma\u00eetrisez la situation. <\/p>\n\n

        \n
      1. Un logiciel de qualit\u00e9<\/strong><\/li>\n<\/ol>\n\n

        Un code suffisamment bon n’implique pas un code n\u00e9glig\u00e9 ou mal produit. Pour r\u00e9ussir, tous les syst\u00e8mes doivent r\u00e9pondre aux exigences de leurs utilisateurs. Vous pouvez vous astreindre \u00e0 \u00e9crire un logiciel suffisamment bon pour vos utilisateurs, les futurs responsables de la maintenance et votre tranquillit\u00e9 d’esprit. L’\u00e9criture d’un logiciel suffisamment bon vous rend plus productif et rend vos utilisateurs plus heureux. L’\u00e9laboration d’un code satisfaisant suppose simplement que les utilisateurs soient autoris\u00e9s \u00e0 s’engager dans le processus qui consiste \u00e0 d\u00e9cider si ce que vous avez produit est satisfaisant. <\/p>\n\n

        Lorsque vous construisez un code suffisamment bon, sachez quand vous arr\u00eater. Ne ruinez pas un programme exceptionnel par un embellissement et un raffinement excessifs. Passez \u00e0 autre chose et laissez votre code se d\u00e9brouiller seul pendant un certain temps. Il ne sera peut-\u00eatre pas parfait. Ne vous inqui\u00e9tez pas : il ne pourra jamais \u00eatre parfait. Un bon logiciel aujourd’hui vaut mieux qu’un logiciel id\u00e9al dans un an. <\/p>\n\n

        \n Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0<\/em>\n<\/strong>\n Un excellent logiciel aujourd’hui est souvent pr\u00e9f\u00e9rable \u00e0 un logiciel parfait demain.\u00a0\u00bb<\/em>\n<\/strong><\/p>\n\n

        Chapitre 2 : Une approche pragmatique<\/strong><\/p>\n\n

          \n
        1. Les m\u00e9faits de la duplication<\/strong><\/li>\n<\/ol>\n\n

          En tant que programmeur, vous recueillez, organisez, entretenez et exploitez les connaissances. Malheureusement, l’apprentissage n’est pas constant ou fixe et \u00e9volue rapidement. Votre compr\u00e9hension d’une exigence peut changer apr\u00e8s une r\u00e9union avec le client. Cela signifie que vous passez la majeure partie de votre temps \u00e0 essayer de maintenir le code quotidiennement. La plupart des gens pensent que la maintenance commence lorsqu’une application est lanc\u00e9e, qu’elle consiste \u00e0 corriger les bogues et \u00e0 am\u00e9liorer les fonctionnalit\u00e9s. Ces personnes se trompent. La maintenance n’est pas une activit\u00e9 distincte, mais une partie du processus de d\u00e9veloppement, car de nouvelles exigences apparaissent au fur et \u00e0 mesure que vous concevez le code. <\/p>\n\n

          La seule fa\u00e7on de d\u00e9velopper des logiciels de mani\u00e8re fiable et de rendre vos d\u00e9veloppements plus faciles \u00e0 comprendre et \u00e0 maintenir est de suivre le principe DRY (Don’t Repeat Yourself)<\/strong>: Chaque \u00e9l\u00e9ment de connaissance doit avoir une repr\u00e9sentation unique, non ambigu\u00eb et faisant autorit\u00e9 au sein d’un syst\u00e8me.<\/p>\n\n

          La plupart des doublons que nous observons entrent dans l’une des cat\u00e9gories suivantes : <\/p>\n\n

            \n
          • Duplication impos\u00e9e. <\/strong>Vous estimez que vous n’avez pas le choix – l’environnement semble exiger la r\u00e9plication.<\/li>\n\n\n\n
          • Duplication involontaire.<\/strong> Vous ne vous rendez pas compte que vous dupliquez les informations.<\/li>\n\n\n\n
          • Duplication impatiente.<\/strong> Vous devenez paresseux et vous dupliquez parce que cela semble plus facile.<\/li>\n\n\n\n
          • Duplication entre d\u00e9veloppeurs.<\/strong> Plusieurs personnes au sein d’une \u00e9quipe reproduisent une information sans s’en rendre compte.<\/li>\n<\/ul>\n\n
              \n
            1. R\u00e9versibilit\u00e9.<\/strong><\/li>\n<\/ol>\n\n

              Les changements n’ont pas besoin d’\u00eatre extr\u00eames ni m\u00eame imm\u00e9diats. Mais \u00e0 mesure que le temps passe et que votre projet progresse, vous pouvez vous retrouver coinc\u00e9 dans une position intenable. L’\u00e9quipe de projet s’engage sur une cible plus petite avec des d\u00e9cisions critiques, cr\u00e9ant une version de la r\u00e9alit\u00e9 avec moins d’options. Le probl\u00e8me est que les d\u00e9cisions critiques ne sont pas facilement r\u00e9versibles. <\/p>\n\n

              Rien n’est \u00e9ternel, et si vous vous appuyez fortement sur un fait, vous pouvez presque garantir qu’il changera. Pr\u00e9voyez la r\u00e9versibilit\u00e9, car aucune d\u00e9cision n’est d\u00e9finitive. Visez la flexibilit\u00e9 du code, de l’architecture et de l’int\u00e9gration des fournisseurs. <\/p>\n\n

              En respectant des recommandations telles que le principe DRY, le d\u00e9couplage et l’utilisation de m\u00e9tadonn\u00e9es, vous n’aurez pas \u00e0 prendre de nombreuses d\u00e9cisions critiques et irr\u00e9versibles.<\/p>\n\n

                \n
              1. Balles tra\u00e7antes<\/strong><\/li>\n<\/ol>\n\n

                Les balles traceuses vous aident \u00e0 trouver rapidement votre cible dans des circonstances r\u00e9elles et vous fournissent, ainsi qu’\u00e0 vos utilisateurs, un retour d’information. Un code traceur peut \u00eatre une fonctionnalit\u00e9 unique mise en \u0153uvre de bout en bout dans toutes les couches. Un code traceur atteint rapidement la cible et fournit un retour d’information imm\u00e9diat. D’un point de vue pratique, il s’agit d’une solution relativement peu co\u00fbteuse. Pour obtenir le m\u00eame effet dans le code, nous cherchons quelque chose qui nous am\u00e8ne d’une exigence \u00e0 un aspect du syst\u00e8me final rapidement, visiblement et de mani\u00e8re r\u00e9p\u00e9t\u00e9e. <\/p>\n\n

                Avantages<\/strong><\/p>\n\n

                  \n
                • Vous disposez d’une plate-forme d’int\u00e9gration.<\/li>\n\n\n\n
                • Vous avez une meilleure id\u00e9e des progr\u00e8s r\u00e9alis\u00e9s.<\/li>\n\n\n\n
                • Les utilisateurs ont la possibilit\u00e9 de voir quelque chose qui fonctionne tr\u00e8s t\u00f4t.<\/li>\n\n\n\n
                • Participez \u00e0 la construction d’une structure de travail.<\/li>\n<\/ul>\n\n

                  Code traceur ou prototypage<\/strong><\/p>\n\n

                  Vous pourriez penser que le concept de code traceur n’est rien d’autre que du prototypage ; il y a une diff\u00e9rence. Lors du prototypage, vous cherchez \u00e0 explorer des aspects sp\u00e9cifiques du syst\u00e8me final. Avec un prototype r\u00e9el, vous jetterez tout ce que vous avez assembl\u00e9 en essayant le concept et vous le recoderez correctement en utilisant les le\u00e7ons que vous avez apprises. L’approche du code traceur aborde un probl\u00e8me diff\u00e9rent. Vous devez savoir comment l’application dans son ensemble s’articule. Vous voulez montrer \u00e0 vos utilisateurs comment les interactions fonctionneront dans la pratique et donner \u00e0 vos d\u00e9veloppeurs un squelette architectural sur lequel accrocher le code. <\/p>\n\n

                  Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Rien n’est plus dangereux qu’une id\u00e9e si c’est la seule que l’on ait.\u00a0\u00bb <\/em><\/strong><\/p>\n\n

                  Chapitre trois : Les outils de base<\/strong><\/p>\n\n

                  \"\"<\/figure>\n\n
                    \n
                  1. Le pouvoir du texte simple<\/strong><\/li>\n<\/ol>\n\n

                    En tant que programmeur pragmatique, votre mat\u00e9riau de base est la connaissance. Vous recueillez les exigences comme des connaissances et vous les exprimez ensuite dans vos conceptions, vos impl\u00e9mentations, vos tests et vos documents. Le meilleur format pour stocker les connaissances est le texte brut. <\/p>\n\n

                    Qu’est-ce que le texte brut ?<\/p>\n\n

                    Le texte brut comprend des caract\u00e8res imprimables afin que les gens puissent le lire et le comprendre directement. Avec le texte brut, vous vous donnez la possibilit\u00e9 de manipuler les connaissances \u00e0 la fois manuellement et par programme en utilisant pratiquement tous les outils \u00e0 votre disposition. <\/p>\n\n

                      \n
                    1. Jeux de coquilles<\/strong><\/li>\n<\/ol>\n\n

                      Tout menuisier a besoin d’un \u00e9tabli appropri\u00e9, solide et fiable, o\u00f9 il peut poser ses pi\u00e8ces \u00e0 une hauteur convenable pendant qu’il les travaille. <\/p>\n\n

                      En tant que programmeur manipulant des fichiers texte, votre poste de travail est l’interpr\u00e9teur de commandes. L’invite de l’interpr\u00e9teur de commandes vous permet d’invoquer l’ensemble de votre r\u00e9pertoire d’outils. L’invite de l’interpr\u00e9teur de commandes vous permet de lancer des applications, des d\u00e9bogueurs, des navigateurs, des \u00e9diteurs et des utilitaires. Vous pouvez rechercher des fichiers, interroger l’\u00e9tat du syst\u00e8me et filtrer les r\u00e9sultats. En programmant l’interpr\u00e9teur de commandes, vous pouvez cr\u00e9er des macro-commandes multiplex pour les activit\u00e9s que vous effectuez souvent. <\/p>\n\n

                      Utilitaires Shell et syst\u00e8mes Windows<\/strong><\/p>\n\n

                      Bien que les shells de commande fournis par les syst\u00e8mes Windows s’am\u00e9liorent progressivement, les utilitaires de ligne de commande Windows restent inf\u00e9rieurs \u00e0 leurs homologues Linux\/Unix. Cependant, tout n’est pas perdu. <\/p>\n\n

                      Cygnus Solutions propose un paquetage appel\u00e9 Cygwin. En plus de fournir une couche de compatibilit\u00e9 Linux\/Unix pour Windows, Cygwin est livr\u00e9 avec une collection de plus de 120 utilitaires Unix, y compris les favoris tels que 1s, grep et find. Les utilitaires et les biblioth\u00e8ques peuvent \u00eatre t\u00e9l\u00e9charg\u00e9s et utilis\u00e9s gratuitement, mais lisez leur licence. La distribution Cygwin est livr\u00e9e avec l’interpr\u00e9teur de commandes Bash. <\/p>\n\n

                        \n
                      1. L’\u00e9dition de puissance<\/strong><\/li>\n<\/ol>\n\n

                        Les outils sont le prolongement de votre main. Cela s’applique aux \u00e9diteurs plus qu’\u00e0 tout autre outil logiciel. Choisissez un \u00e9diteur qui vous permettra de manipuler du texte aussi facilement que possible, car le texte est la mati\u00e8re premi\u00e8re de la programmation. <\/p>\n\n

                        Un \u00e9diteur<\/strong><\/p>\n\n

                        \"\"<\/figure>\n\n

                        Il est pr\u00e9f\u00e9rable de conna\u00eetre parfaitement un seul \u00e9diteur et de l’utiliser pour toutes les t\u00e2ches d’\u00e9dition : code, documentation, m\u00e9mos, administration du syst\u00e8me, etc. Avec plusieurs \u00e9diteurs, vous risquez d’\u00eatre confront\u00e9 au chaos et \u00e0 la confusion des temps modernes. Vous devrez peut-\u00eatre utiliser l’\u00e9diteur int\u00e9gr\u00e9 dans l’IDE de chaque langue pour le codage, un produit bureautique tout-en-un pour la documentation et peut-\u00eatre un autre \u00e9diteur int\u00e9gr\u00e9 pour l’envoi de courriels. M\u00eame les touches que vous utilisez pour \u00e9diter les lignes de commande dans l’interpr\u00e9teur de commandes peuvent \u00eatre diff\u00e9rentes. Il est difficile d’\u00eatre comp\u00e9tent dans l’un ou l’autre de ces environnements si vous disposez d’un ensemble diff\u00e9rent de conventions et de commandes d’\u00e9dition dans chacun d’eux. <\/p>\n\n

                        Choisissez donc un seul \u00e9diteur, apprenez \u00e0 le conna\u00eetre en profondeur et utilisez-le pour toutes les t\u00e2ches d’\u00e9dition. Utilisez un seul \u00e9diteur ou un seul ensemble de raccourcis clavier pour toutes les activit\u00e9s d’\u00e9dition de texte. Vous n’aurez plus besoin de vous arr\u00eater et de r\u00e9fl\u00e9chir pour manipuler du texte : les frappes n\u00e9cessaires seront un r\u00e9flexe. L’\u00e9diteur sera le prolongement de votre main, les touches chanteront en se frayant un chemin \u00e0 travers le texte et la pens\u00e9e. Assurez-vous que l’\u00e9diteur que vous choisissez est disponible sur toutes les plates-formes que vous utilisez. Emacs, vi, CRiSP, Brief et d’autres sont disponibles sur plusieurs plates-formes, souvent dans des versions avec ou sans interface graphique (\u00e9cran de texte). <\/p>\n\n

                        Caract\u00e9ristiques de l’\u00e9diteur :<\/p>\n\n

                          \n
                        • Configurable<\/li>\n\n\n\n
                        • Extensible<\/li>\n\n\n\n
                        • Programmable<\/li>\n<\/ul>\n\n

                          Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Les outils amplifient votre talent. Plus vos outils sont performants et mieux vous savez les utiliser, plus vous pouvez \u00eatre productif.\u00a0\u00bb<\/em><\/strong><\/p>\n\n

                          Chapitre quatre : La parano\u00efa pragmatique<\/strong><\/p>\n\n

                            \n
                          1. Conception par contrat<\/strong><\/li>\n<\/ol>\n\n

                            Le concept de conception par contrat est une technique simple mais puissante qui se concentre sur la documentation et l’acceptation des droits et des responsabilit\u00e9s des modules logiciels afin de garantir l’exactitude du programme. Un programme correct ne fait ni plus ni moins que ce qu’il pr\u00e9tend faire. La documentation et la v\u00e9rification de cette affirmation sont au c\u0153ur de la conception par contrat. Chaque fonction et m\u00e9thode d’un syst\u00e8me logiciel fait quelque chose. Avant de commencer, la routine peut avoir des attentes quant \u00e0 l’\u00e9tat du monde. Les attentes et les revendications comprennent <\/p>\n\n

                              \n
                            • Conditions pr\u00e9alables : Qu’est-ce qui doit \u00eatre valide pour que la routine soit appel\u00e9e ?<\/li>\n\n\n\n
                            • Invariants de classe : Une classe garantit que cette condition est toujours effective du point de vue de l’appelant.<\/li>\n\n\n\n
                            • Postconditions : Le fait que la routine ait une postcondition implique qu’elle conclura : les boucles infinies ne sont pas autoris\u00e9es.<\/li>\n<\/ul>\n\n

                              Mise en \u0153uvre de la conception par contrat<\/strong><\/p>\n\n

                              Le principal avantage de l’utilisation de DBC est qu’elle met au premier plan la question des exigences et des garanties. Le simple fait d’\u00e9num\u00e9rer, au moment de la conception, l’\u00e9tendue du domaine d’entr\u00e9e, les conditions limites et ce que la routine promet de fournir ou ne promet pas de fournir constitue un pas de g\u00e9ant dans l’\u00e9criture d’un meilleur logiciel. Si vous n’indiquez pas ces \u00e9l\u00e9ments, vous programmez par co\u00efncidence et c’est l\u00e0 que de nombreux projets commencent, se terminent et \u00e9chouent. Dans les langages qui ne prennent pas en charge DBC dans le code, vous ne pouvez pas aller plus loin, ce qui n’est pas si mal. Apr\u00e8s tout, DBC est une technique de conception. <\/p>\n\n

                                \n
                              1. Les programmes morts ne mentent pas<\/strong><\/li>\n<\/ol>\n\n

                                Il est facile de tomber dans la mentalit\u00e9 du \u00ab\u00a0\u00e7a ne peut pas arriver\u00a0\u00bb. La plupart d’entre vous ont d\u00e9j\u00e0 \u00e9crit du code qui ne v\u00e9rifiait pas qu’un fichier se fermait correctement ou qu’une instruction de trace \u00e9tait \u00e9crite comme pr\u00e9vu. Toutes choses \u00e9tant \u00e9gales par ailleurs, il est probable que vous n’ayez pas eu besoin de le faire, le code en question n’aurait pas \u00e9chou\u00e9 dans des conditions normales. Mais vous codez de mani\u00e8re d\u00e9fensive. Vous recherchez des pointeurs erron\u00e9s dans d’autres parties de votre programme et vous mettez la pile \u00e0 la poubelle. Vous v\u00e9rifiez que les versions charg\u00e9es des biblioth\u00e8ques partag\u00e9es sont correctes. <\/p>\n\n

                                Toutes les erreurs vous donnent des informations. Vous pourriez vous convaincre que l’erreur ne peut pas se produire et choisir de l’ignorer. Au lieu de cela, un programmeur pragmatique se dit que quelque chose de tr\u00e8s, tr\u00e8s mauvais s’est produit s’il y a une erreur. <\/p>\n\n

                                Crash, Don’t Trash (ne pas jeter \u00e0 la poubelle)<\/strong><\/p>\n\n

                                \"\"<\/figure>\n\n

                                L’un des avantages de d\u00e9tecter les probl\u00e8mes le plus t\u00f4t possible est que vous pouvez vous \u00e9craser plus t\u00f4t.<\/p>\n\n

                                Et bien souvent, le plantage de votre programme est la meilleure chose que vous puissiez faire. L’alternative peut \u00eatre de continuer \u00e0 \u00e9crire des donn\u00e9es corrompues dans une base de donn\u00e9es robuste ou de commander \u00e0 la machine \u00e0 laver son vingti\u00e8me cycle d’essorage cons\u00e9cutif. <\/p>\n\n

                                  \n
                                1. Programmation assertive<\/strong><\/li>\n<\/ol>\n\n

                                  Le compte ne peut pas \u00eatre n\u00e9gatif, l’impression ne peut pas \u00e9chouer, la journalisation ne peut pas \u00e9chouer ou cela ne peut jamais se produire. Ne pratiquez pas ce genre de tromperie, en particulier lors du codage. Si cela ne peut pas arriver, appliquez des assertions pour vous assurer que cela n’arrivera pas. <\/p>\n\n

                                  Chaque fois que vous pensez que \u00ab\u00a0cela ne pourrait jamais arriver\u00a0\u00bb, ajoutez du code pour le v\u00e9rifier. La mani\u00e8re la plus simple de le faire est d’utiliser des assertions. Dans la plupart des impl\u00e9mentations C et C++, vous trouverez une forme d’assert ou de macro assert qui v\u00e9rifie une condition bool\u00e9enne. Ces macros peuvent s’av\u00e9rer pr\u00e9cieuses. Les assertions permettent \u00e9galement de v\u00e9rifier le fonctionnement d’un algorithme. Supposons que vous ayez \u00e9crit un algorithme intelligent ; les assertions v\u00e9rifieront qu’il fonctionne. <\/p>\n\n

                                  N’appliquez pas d’assertions \u00e0 la place d’une v\u00e9ritable gestion des erreurs. Les assertions v\u00e9rifient des choses qui ne devraient jamais se produire et assurez-vous que la m\u00e9thode d’assertion que vous utilisez n’a pas d’effets secondaires susceptibles de cr\u00e9er de nouvelles erreurs. <\/p>\n\n

                                  Laissez les affirmations en place<\/strong><\/p>\n\n

                                  Les personnes qui \u00e9crivent des compilateurs et des environnements linguistiques ont une interpr\u00e9tation erron\u00e9e des assertions qui est largement r\u00e9pandue. Cette interpr\u00e9tation est la suivante : \u00ab\u00a0Les assertions ajoutent une certaine surcharge au code. Parce qu’elles v\u00e9rifient des choses qui ne devraient jamais se produire, elles ne seront d\u00e9clench\u00e9es que par un bogue dans le code. Une fois que le code a \u00e9t\u00e9 test\u00e9 et livr\u00e9, d\u00e9sactivez les assertions pour acc\u00e9l\u00e9rer l’ex\u00e9cution du code.\u00a0\u00bb <\/p>\n\n

                                  Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Les assertions ajoutent une certaine surcharge au code. Parce qu’elles v\u00e9rifient des choses qui ne devraient jamais se produire, elles ne seront d\u00e9clench\u00e9es que par un bogue dans le code. Une fois que le code a \u00e9t\u00e9 test\u00e9 et livr\u00e9, elles ne sont plus n\u00e9cessaires et doivent \u00eatre d\u00e9sactiv\u00e9es pour acc\u00e9l\u00e9rer l’ex\u00e9cution du code.\u00a0\u00bb<\/em><\/strong><\/p>\n\n

                                  Chapitre 5 : Se plier ou se rompre<\/strong><\/p>\n\n

                                    \n
                                  1. Le d\u00e9couplage et la loi de D\u00e9m\u00e9ter<\/strong><\/li>\n<\/ol>\n\n

                                    Organisez votre code en modules et contr\u00f4lez l’interaction entre eux. Si un module est compromis et doit \u00eatre remplac\u00e9, les autres modules doivent continuer \u00e0 fonctionner. <\/p>\n\n

                                    Minimiser l’accouplement<\/p>\n\n

                                    Il n’y a rien de mal \u00e0 ce que les modules se connaissent les uns les autres. Cependant, vous devez faire attention au nombre d’autres modules avec lesquels vous interagissez et, plus important encore, \u00e0 la mani\u00e8re dont vous interagissez avec eux. Lorsque vous demandez un service sp\u00e9cifique \u00e0 un objet, vous souhaitez que ce service soit ex\u00e9cut\u00e9 en votre nom. Vous ne voulez pas que l’objet vous donne une entit\u00e9 tierce avec laquelle vous devez traiter pour obtenir le service requis. <\/p>\n\n

                                    La loi de D\u00e9m\u00e9ter<\/strong><\/p>\n\n

                                    La loi de D\u00e9m\u00e9ter pour les fonctions stipule que toute m\u00e9thode d’un objet ne doit appeler que des processus appartenant \u00e0 lui-m\u00eame, tout param\u00e8tre pass\u00e9 dans la m\u00e9thode, tout objet qu’il a cr\u00e9\u00e9 et tout objet compos\u00e9 d\u00e9tenu directement. La loi de D\u00e9m\u00e9ter vise \u00e0 minimiser le couplage entre les modules d’un programme donn\u00e9 ; elle vous emp\u00eache de p\u00e9n\u00e9trer dans un objet pour acc\u00e9der aux m\u00e9thodes d’un troisi\u00e8me objet. L’\u00e9criture d’un code \u00ab\u00a0timide\u00a0\u00bb honore la loi de Demeter et permet d’atteindre l’objectif de minimisation du couplage entre les modules. <\/p>\n\n

                                      \n
                                    1. M\u00e9taprogrammation<\/strong><\/li>\n<\/ol>\n\n

                                      Les d\u00e9tails nuisent consid\u00e9rablement \u00e0 votre code parfait s’ils changent fr\u00e9quemment. Chaque fois que vous devez modifier le code pour l’adapter \u00e0 une modification de la logique commerciale, de la l\u00e9gislation ou des go\u00fbts du jour de la direction, vous courez le risque de casser le syst\u00e8me en introduisant un nouveau bogue. <\/p>\n\n

                                      Assez de d\u00e9tails ! Sortez-les du code. Pendant que vous y \u00eates, vous pouvez rendre votre code hautement configurable et \u00ab\u00a0souple\u00a0\u00bb. C’est-\u00e0-dire facilement adaptable aux changements.<\/p>\n\n

                                      Configuration dynamique<\/strong><\/p>\n\n

                                      Configurez, n’int\u00e9grez pas. Vous devez faire en sorte que vos syst\u00e8mes soient hautement configurables. Il ne s’agit pas seulement de couleurs d’\u00e9cran ou de texte d’invite, mais d’\u00e9l\u00e9ments profond\u00e9ment ancr\u00e9s tels que le choix des algorithmes, des produits de base de donn\u00e9es, de la technologie des logiciels interm\u00e9diaires et du style de l’interface utilisateur, qui doivent \u00eatre appliqu\u00e9s en tant qu’options de configuration et non par le biais de l’int\u00e9gration ou de l’ing\u00e9nierie. <\/p>\n\n

                                      Quand configurer<\/strong><\/p>\n\n

                                      Repr\u00e9sentez vos m\u00e9tadonn\u00e9es de configuration en texte clair ; cela vous facilitera la vie. Mais quand un programme doit-il lire cette configuration ? De nombreux programmes n’analysent ce type de donn\u00e9es qu’au d\u00e9marrage, ce qui est regrettable car vous serez oblig\u00e9 de red\u00e9marrer l’application lorsque vous aurez besoin d’en modifier la pr\u00e9sentation. Une approche plus souple consiste \u00e0 \u00e9crire des programmes qui rechargent leur configuration en cours d’ex\u00e9cution. Bien que cette flexibilit\u00e9 ait un co\u00fbt, elle est plus complexe \u00e0 mettre en \u0153uvre. <\/p>\n\n

                                      Pensez donc \u00e0 la mani\u00e8re dont les utilisateurs se serviront de votre application : s’il s’agit d’un processus serveur de longue dur\u00e9e, vous devrez pr\u00e9voir un moyen de relire et d’appliquer les m\u00e9tadonn\u00e9es pendant que le programme est en cours d’ex\u00e9cution. Pour une petite application client \u00e0 interface graphique qui red\u00e9marre rapidement, vous n’en aurez peut-\u00eatre pas besoin. <\/p>\n\n

                                        \n
                                      1. Couplage temporel<\/strong><\/li>\n<\/ol>\n\n

                                        Ici, l’auteur parle du temps comme d’un \u00e9l\u00e9ment de conception du logiciel lui-m\u00eame. Deux aspects du temps sont importants pour vous : la coexistence (les choses qui se produisent simultan\u00e9ment) et l’ordonnancement (les positions relatives des choses dans le temps). Dans le cadre du couplage temporel, la coexistence est toujours appel\u00e9e avant l’ordre ; vous ne pouvez ex\u00e9cuter qu’un seul rapport \u00e0 la fois ; apr\u00e8s, attendez que l’\u00e9cran se redessine avant de cliquer sur un bouton. <\/p>\n\n

                                        Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Aucun g\u00e9nie ne peut venir \u00e0 bout d’un souci du d\u00e9tail\u00a0\u00bb.<\/em><\/strong><\/p>\n\n

                                        Chapitre six : Pendant que vous codez<\/strong><\/p>\n\n

                                          \n
                                        1. Programmation par co\u00efncidence<\/strong><\/li>\n<\/ol>\n\n

                                          Des centaines de pi\u00e8ges vous guettent chaque jour en tant que d\u00e9veloppeur. N’oubliez pas de ne pas tirer de fausses conclusions. \u00c9vitez de programmer par co\u00efncidence, en vous fiant \u00e0 la chance et aux succ\u00e8s accidentels, au profit d’une programmation d\u00e9lib\u00e9r\u00e9e. Lorsque vous programmez par co\u00efncidence et que votre code \u00e9choue, vous ne saurez pas pourquoi il a \u00e9chou\u00e9 parce que vous ne saviez pas pourquoi il fonctionnait en premier lieu, compte tenu des tests limit\u00e9s que vous avez effectu\u00e9s. <\/p>\n\n

                                          Accidents de mise en \u0153uvre<\/strong><\/p>\n\n

                                          Les accidents de mise en \u0153uvre sont des choses qui se produisent simplement parce que c’est ainsi que le code est \u00e9crit. Vous finissez par vous appuyer sur des erreurs ou des conditions limites non document\u00e9es. La condition limite sur laquelle vous vous appuyez peut n’\u00eatre qu’un accident. Dans d’autres circonstances (une r\u00e9solution d’\u00e9cran diff\u00e9rente, par exemple), elle pourrait se comporter diff\u00e9remment. <\/p>\n\n

                                          Les comportements non document\u00e9s peuvent changer avec la prochaine version de la biblioth\u00e8que.<\/p>\n\n

                                          Comment programmer d\u00e9lib\u00e9r\u00e9ment<\/strong><\/p>\n\n

                                            \n
                                          • Ne codez pas les yeux band\u00e9s.<\/li>\n\n\n\n
                                          • Ne vous fiez qu’\u00e0 des \u00e9l\u00e9ments fiables. Ne vous fiez pas aux accidents ou aux hypoth\u00e8ses. <\/li>\n\n\n\n
                                          • Documentez vos hypoth\u00e8ses.<\/li>\n<\/ul>\n\n
                                              \n
                                            1. Vitesse de l’algorithme<\/strong><\/li>\n<\/ol>\n\n

                                              En tant que programmeur pragmatique, vous \u00e9valuez les ressources des algorithmes, telles que le temps, le processeur et la m\u00e9moire. La plupart des algorithmes non triviaux g\u00e8rent une certaine forme d’entr\u00e9e variable ; la taille de cette entr\u00e9e aura un impact sur l’algorithme. Plus l’information est importante, plus le temps d’ex\u00e9cution est long ou plus la m\u00e9moire est utilis\u00e9e. <\/p>\n\n

                                              Vous constaterez que vous v\u00e9rifiez inconsciemment les exigences en mati\u00e8re de temps d’ex\u00e9cution et de m\u00e9moire chaque fois que vous \u00e9crivez quelque chose qui contient des boucles ou des appels r\u00e9cursifs. Ce processus confirme rapidement que vos actions sont raisonnables compte tenu des circonstances. Par cons\u00e9quent, vous vous retrouvez \u00e0 effectuer une analyse plus d\u00e9taill\u00e9e. C’est alors que la notation O() devient utile. La notation O() est un moyen math\u00e9matique de traiter les approximations. <\/p>\n\n

                                                \n
                                              1. Refonte<\/strong><\/li>\n<\/ol>\n\n

                                                Le code doit \u00e9voluer, il n’est pas statique. Au fur et \u00e0 mesure qu’un programme se d\u00e9veloppe, il devient n\u00e9cessaire de repenser les d\u00e9cisions ant\u00e9rieures et de retravailler certaines parties du code. La r\u00e9\u00e9criture, la restructuration et la r\u00e9architecture d’un corps de code existant, en modifiant sa structure interne sans changer son comportement externe, sont connues sous le nom de \u00ab\u00a0refactoring\u00a0\u00bb. <\/p>\n\n

                                                Quand faut-il remanier ?<\/strong><\/p>\n\n

                                                Si vous tombez sur une pierre d’achoppement parce que le code n’est plus tout \u00e0 fait adapt\u00e9 ou que vous remarquez deux choses que vous devriez fusionner, n’h\u00e9sitez pas \u00e0 le modifier. Voici quelques \u00e9l\u00e9ments qui peuvent faire qu’un code m\u00e9rite d’\u00eatre remani\u00e9 : <\/p>\n\n

                                                Duplication. Vous avez d\u00e9couvert une violation du principe DRY (Don’t Repeat Yourself). <\/p>\n\n

                                                Conception non orthogonale. Vous avez d\u00e9couvert un code ou une proc\u00e9dure qui pourrait \u00eatre rendu plus orthogonal (orthogonalit\u00e9). <\/p>\n\n

                                                Des connaissances d\u00e9pass\u00e9es. Les choses changent, les exigences d\u00e9rivent et votre compr\u00e9hension du probl\u00e8me augmente. Le code doit suivre. <\/p>\n\n

                                                Performance. Vous devez d\u00e9placer des fonctionnalit\u00e9s d’une zone du syst\u00e8me \u00e0 une autre pour am\u00e9liorer les performances. <\/p>\n\n

                                                  \n
                                                1. Code facile \u00e0 tester<\/strong><\/li>\n<\/ol>\n\n

                                                  Dans les puces et les syst\u00e8mes plus complexes, les d\u00e9veloppeurs de mat\u00e9riel incluent des fonctions telles qu’un autotest int\u00e9gr\u00e9 (BIST) complet qui ex\u00e9cute des diagnostics de base en interne et un m\u00e9canisme d’acc\u00e8s aux tests (TAM) qui fournit un harnais de test permettant \u00e0 l’environnement externe de fournir des stimuli et de recueillir les r\u00e9ponses de la puce. Vous pouvez faire la m\u00eame chose dans les logiciels, int\u00e9grer la testabilit\u00e9 dans le logiciel d\u00e8s le d\u00e9but et tester chaque \u00e9l\u00e9ment en d\u00e9tail avant d’essayer de les relier entre eux. <\/p>\n\n

                                                  Tests unitaires<\/strong><\/p>\n\n

                                                  Les tests au niveau de la puce pour le mat\u00e9riel sont \u00e9quivalents aux tests unitaires pour les logiciels. Les tests sont effectu\u00e9s sur chaque module de mani\u00e8re isol\u00e9e afin de v\u00e9rifier son comportement. Vous pouvez mieux comprendre comment un module r\u00e9agira dans le vaste monde une fois que vous l’avez test\u00e9 de mani\u00e8re approfondie dans des conditions contr\u00f4l\u00e9es. <\/p>\n\n

                                                  Un test unitaire de logiciel est un code qui exerce un module. En g\u00e9n\u00e9ral, le test unitaire met en place un environnement artificiel et \u00e9voque ensuite des routines dans le module test\u00e9. Le test unitaire v\u00e9rifie ensuite les r\u00e9sultats obtenus, soit par rapport \u00e0 des valeurs connues, soit par rapport aux r\u00e9sultats des ex\u00e9cutions pr\u00e9c\u00e9dentes du m\u00eame test. <\/p>\n\n

                                                  Plus tard, lorsque vous assemblerez vos \u00ab\u00a0circuits int\u00e9gr\u00e9s logiciels\u00a0\u00bb en un syst\u00e8me complet, vous aurez la certitude que les diff\u00e9rentes parties fonctionnent comme pr\u00e9vu. Vous pourrez alors utiliser les m\u00eames moyens de test unitaire pour tester le syst\u00e8me dans son ensemble. <\/p>\n\n

                                                  Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Tous les logiciels que vous \u00e9crivez seront test\u00e9s – si ce n’est pas par vous et votre \u00e9quipe, ce sera par les utilisateurs finaux – alors autant pr\u00e9voir des tests approfondis.\u00a0\u00bb<\/em><\/strong><\/p>\n\n

                                                  Chapitre sept : Avant le projet<\/strong><\/p>\n\n

                                                  \"\"<\/figure>\n\n
                                                    \n
                                                  1. Le puits d’exigence<\/strong><\/li>\n<\/ol>\n\n

                                                    Le recueil des besoins est une \u00e9tape pr\u00e9coce du projet. La collecte implique que les exigences sont d\u00e9j\u00e0 l\u00e0, il suffit de les trouver. Mettez-les dans votre panier et continuez votre chemin. Bien que cela ne fonctionne pas comme \u00e7a, les exigences font rarement surface. Elles sont enfouies sous des couches de suppositions, d’id\u00e9es fausses et de politiques. <\/p>\n\n

                                                    Recherche d’exigences<\/strong><\/p>\n\n

                                                    Comment identifier un besoin r\u00e9el lorsque vous creusez dans la poussi\u00e8re environnante ? La r\u00e9ponse est \u00e0 la fois complexe et simple. La r\u00e9ponse directe est l’\u00e9nonc\u00e9 de quelque chose qui doit \u00eatre accompli. D’un autre c\u00f4t\u00e9, tr\u00e8s peu d’exigences sont claires, ce qui rend l’analyse des exigences complexe. <\/p>\n\n

                                                    Si l’exigence est formul\u00e9e comme suit : \u00ab\u00a0Seul le personnel peut consulter un dossier d’employ\u00e9\u00a0\u00bb, vous devrez coder un test simple chaque fois que l’application acc\u00e8de \u00e0 ces fichiers. En revanche, si l’exigence est \u00ab\u00a0Seuls les utilisateurs autoris\u00e9s peuvent acc\u00e9der \u00e0 un dossier d’employ\u00e9\u00a0\u00bb, le d\u00e9veloppeur concevra et mettra probablement en \u0153uvre une sorte de syst\u00e8me de contr\u00f4le d’acc\u00e8s. En cas de changement de politique, seules les m\u00e9tadonn\u00e9es de ce syst\u00e8me devront \u00eatre mises \u00e0 jour. En rassemblant les exigences de cette mani\u00e8re, vous obtiendrez un syst\u00e8me bien con\u00e7u pour prendre en charge les m\u00e9tadonn\u00e9es. <\/p>\n\n

                                                      \n
                                                    1. R\u00e9soudre des \u00e9nigmes impossibles<\/strong><\/li>\n<\/ol>\n\n

                                                      Pensez aux puzzles du monde r\u00e9el que l’on trouve dans les cadeaux de No\u00ebl ou dans les vide-greniers. Vous devez retirer l’anneau ou faire entrer les pi\u00e8ces en forme de T dans la bo\u00eete. Vous retirez l’anneau et d\u00e9couvrez rapidement que les solutions apparentes ne permettent pas de r\u00e9soudre le puzzle. La r\u00e9ponse se trouve ailleurs. Le secret pour r\u00e9soudre l’\u00e9nigme est d’identifier les v\u00e9ritables contraintes et d’y trouver une solution. Certaines contraintes sont absolues, d’autres ne sont que des id\u00e9es re\u00e7ues. Les contraintes fondamentales doivent \u00eatre respect\u00e9es, m\u00eame si elles semblent d\u00e9plaisantes ou stupides. En revanche, certaines contraintes apparentes peuvent \u00eatre inexactes. <\/p>\n\n

                                                      Ne pensez pas en dehors de la bo\u00eete – trouvez la bo\u00eete<\/strong><\/p>\n\n

                                                      Lorsque vous \u00eates confront\u00e9 \u00e0 un probl\u00e8me insoluble, \u00e9num\u00e9rez toutes les possibilit\u00e9s qui s’offrent \u00e0 vous.<\/p>\n\n

                                                      Ne rejetez rien, m\u00eame si cela vous semble inutilisable ou stupide. Parcourez la liste et expliquez pourquoi vous ne pouvez pas emprunter telle ou telle voie. Pouvez-vous le prouver ? <\/p>\n\n

                                                        \n
                                                      1. Pas avant que vous ne soyez pr\u00eat<\/strong><\/li>\n<\/ol>\n\n

                                                        Lorsque vous ressentez un doute ou une r\u00e9ticence persistante face \u00e0 une t\u00e2che, pr\u00eatez-y attention. Il se peut que vous ne parveniez pas \u00e0 d\u00e9terminer exactement ce qui ne va pas. Donnez-lui du temps et vos doutes se cristalliseront probablement en quelque chose de plus solide, quelque chose que vous pourrez r\u00e9soudre. Le d\u00e9veloppement de logiciels n’est pas encore une science. Laissez votre instinct contribuer \u00e0 vos performances. <\/p>\n\n

                                                        Bon jugement ou procrastination ?<\/strong><\/p>\n\n

                                                        <\/p>\n\n

                                                        Le lancement d’un nouveau projet ou m\u00eame d’un nouveau module dans le cadre d’un projet existant peut \u00eatre une exp\u00e9rience douloureuse. Nombreux sont ceux qui pr\u00e9f\u00e8rent remettre \u00e0 plus tard l’engagement initial de commencer. Alors, comment savoir si vous \u00eates en train de procrastiner plut\u00f4t que d’attendre de mani\u00e8re responsable que tous les \u00e9l\u00e9ments se mettent en place ? <\/p>\n\n

                                                        Dans ces circonstances, une technique qui vous conviendra est le prototypage. Choisissez un domaine qui vous semble difficile et commencez \u00e0 produire des preuves de concept. Peu apr\u00e8s, vous penserez que vous perdez votre temps. Cet ennui est probablement une bonne indication que votre r\u00e9ticence initiale n’\u00e9tait qu’un d\u00e9sir de repousser l’engagement de commencer. Abandonnez le prototype et lancez-vous dans le d\u00e9veloppement proprement dit. <\/p>\n\n

                                                        Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0La perfection est atteinte, non pas quand il n’y a plus rien \u00e0 ajouter, mais quand il n’y a plus rien \u00e0 enlever….\u00a0\u00bb<\/em><\/strong><\/p>\n\n

                                                        Chapitre huit<\/strong>: Des projets pragmatiques<\/p>\n\n

                                                          \n
                                                        1. Des tests impitoyables<\/strong><\/li>\n<\/ol>\n\n

                                                          Testez t\u00f4t, testez souvent et testez automatiquement. Vous devriez commencer \u00e0 tester d\u00e8s que vous avez le code. D\u00e9veloppez des plans de test \u00e9labor\u00e9s pour vos projets. Les \u00e9quipes qui utilisent des tests automatis\u00e9s ont de bien meilleures chances de r\u00e9ussite. Les tests qui s’ex\u00e9cutent \u00e0 chaque version sont beaucoup plus efficaces que des plans de test sur une \u00e9tag\u00e8re. N’oubliez pas que plus vous trouvez un bogue t\u00f4t, moins il est co\u00fbteux d’y rem\u00e9dier. \u00ab\u00a0Codez un peu, testez un peu. <\/p>\n\n

                                                          Pour que votre projet soit satisfaisant, il doit comporter plus de code de test que de code de production. Le temps perdu \u00e0 produire ce code de test en vaut la peine et co\u00fbte moins cher \u00e0 long terme. Vous avez \u00e9galement une chance de cr\u00e9er un produit dont le nombre de d\u00e9fauts est proche de z\u00e9ro. <\/p>\n\n

                                                            \n
                                                          1. De grandes attentes<\/strong><\/li>\n<\/ol>\n\n

                                                            La r\u00e9ussite du projet de votre \u00e9quipe se mesure \u00e0 la mani\u00e8re dont il r\u00e9pond aux attentes de ses utilisateurs. Si votre projet ne r\u00e9pond pas \u00e0 leurs attentes, il est consid\u00e9r\u00e9 comme un \u00e9chec, quelle que soit la qualit\u00e9 du produit livrable en termes absolus. <\/p>\n\n

                                                            L’effort suppl\u00e9mentaire<\/strong><\/p>\n\n

                                                            D\u00e9passez gentiment les attentes de vos utilisateurs. N’effrayez pas vos utilisateurs, mais surprenez-les. Donnez-leur un peu plus que ce qu’ils attendaient. L’effort suppl\u00e9mentaire requis pour ajouter au syst\u00e8me une fonction orient\u00e9e vers l’utilisateur se paiera de lui-m\u00eame, \u00e0 maintes reprises, en termes de bonne volont\u00e9. <\/p>\n\n

                                                              \n
                                                            1. Fiert\u00e9 et pr\u00e9jug\u00e9s<\/strong><\/li>\n<\/ol>\n\n

                                                              En tant que programmeur pragmatique, vous ne devez pas fuir les responsabilit\u00e9s. Au contraire, vous devez vous r\u00e9jouir des d\u00e9fis qui se pr\u00e9sentent \u00e0 vous et faire conna\u00eetre votre expertise professionnelle. Si vous \u00eates responsable d’une conception ou d’un morceau de code, vous ferez un travail dont vous serez fier. <\/p>\n\n

                                                              Signez votre travail<\/strong><\/p>\n\n

                                                              Soyez fier de votre travail. \u00ab\u00a0Vous avez \u00e9crit ceci et vous devriez \u00eatre fier de votre travail. Votre signature devrait \u00eatre reconnue comme un indicateur de qualit\u00e9. Les gens devraient voir votre nom sur un morceau de code et s’attendre \u00e0 ce qu’il soit solide, bien \u00e9crit, test\u00e9 et document\u00e9 – un travail professionnel r\u00e9alis\u00e9 par un vrai professionnel. <\/p>\n\n

                                                              Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0La civilisation progresse en augmentant le nombre d’op\u00e9rations importantes que nous pouvons effectuer sans r\u00e9fl\u00e9chir.\u00a0\u00bb<\/em><\/strong><\/p>\n\n

                                                              COMMENT CE LIVRE PEUT-IL AIDER LES D\u00c9VELOPPEURS DE LOGICIELS ?<\/strong><\/p>\n\n

                                                              \u00ab\u00a0The Pragmatic Programmer\u00a0\u00bb d’Andrew Hunt et David Thomas est un ouvrage classique sur le d\u00e9veloppement de logiciels qui offre des conseils pratiques et des techniques pour am\u00e9liorer la fa\u00e7on dont les d\u00e9veloppeurs travaillent. Il aborde des sujets tels que le d\u00e9bogage, les tests, l’automatisation et la gestion de projet, ainsi que l’importance de la communication et de l’apprentissage continu. En suivant les conseils de l’ouvrage, les d\u00e9veloppeurs peuvent am\u00e9liorer leurs comp\u00e9tences en mati\u00e8re de codage, accro\u00eetre leur productivit\u00e9, travailler plus efficacement, devenir des membres d’\u00e9quipe plus performants et livrer de meilleurs produits logiciels. <\/p>\n","protected":false},"excerpt":{"rendered":"

                                                              Le programmeur pragmatique est un guide habile et pratique qui donne un aper\u00e7u et les bases pour \u00eatre un bon programmeur, en augmentant votre sp\u00e9cialisation et les technicit\u00e9s dans le d\u00e9veloppement moderne de logiciels. Le livre a \u00e9t\u00e9 publi\u00e9 en octobre 1999. Andrew Hunt y aborde les th\u00e8mes de la responsabilit\u00e9 personnelle et du d\u00e9veloppement […]<\/p>\n","protected":false},"author":1,"featured_media":17632,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"_jet_sm_ready_style":"","_jet_sm_style":"","_jet_sm_controls_values":"","_jet_sm_fonts_collection":"","_jet_sm_fonts_links":"","footnotes":""},"categories":[102],"tags":[],"writer":[],"class_list":["post-19685","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-club-de-lecture"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19685","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/comments?post=19685"}],"version-history":[{"count":1,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19685\/revisions"}],"predecessor-version":[{"id":19686,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19685\/revisions\/19686"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/media\/17632"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/media?parent=19685"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/categories?post=19685"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/tags?post=19685"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/writer?post=19685"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}