{"id":36115,"date":"2019-10-31T22:09:42","date_gmt":"2019-10-31T19:09:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete\/"},"modified":"2019-10-31T22:09:42","modified_gmt":"2019-10-31T19:09:42","slug":"ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","title":{"rendered":"Ne vous engagez pas \u00e0 d\u00e9velopper ce que vous ne comprenez pas","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ne
\n
\nDepuis d\u00e9but 2018, j'occupe le poste de leader\/chef\/developer principal dans l'\u00e9quipe - appelez cela comme vous voulez, mais l'essentiel est que je suis enti\u00e8rement responsable d'un des modules et de tous les d\u00e9veloppeurs qui y travaillent. Ce poste m'offre une nouvelle perspective sur le processus de d\u00e9veloppement, car je suis impliqu\u00e9 dans un plus grand nombre de projets et participe plus activement \u00e0 la prise de d\u00e9cisions. R\u00e9cemment, gr\u00e2ce \u00e0 ces deux circonstances, j'ai r\u00e9alis\u00e9 \u00e0 quel point le niveau de compr\u00e9hension influence le code et l'application.<\/p>\n

La pens\u00e9e que je souhaite exprimer est que la qualit\u00e9 du code (et du produit final) est \u00e9troitement li\u00e9e \u00e0 la mesure dans laquelle les personnes qui con\u00e7oivent et \u00e9crivent le code comprennent ce qu'elles font.<\/p>\n

Vous pensez peut-\u00eatre maintenant : \u00ab Merci, capitaine. Bien s\u00fbr, il serait bon de comprendre ce que l'on \u00e9crit. Sinon, on pourrait aussi bien engager un groupe de singes pour taper al\u00e9atoirement sur des touches, et se satisfaire de cela. \u00bb Et vous avez tout \u00e0 fait raison. Par cons\u00e9quent, je suppose comme acquis que vous comprenez qu'avoir une vue d'ensemble de ce que vous faites est n\u00e9cessaire. Cela peut \u00eatre qualifi\u00e9 de niveau z\u00e9ro de compr\u00e9hension, et nous ne l'aborderons pas en d\u00e9tail. Nous examinerons en d\u00e9tail ce qu'il est n\u00e9cessaire de comprendre et comment cela impacte les d\u00e9cisions que vous prenez chaque jour. Si j'avais su ces choses \u00e0 l'avance, cela m'aurait \u00e9vit\u00e9 de nombreuses heures perdues et du code douteux.
\n<\/a><\/noindex>
\nBien que vous ne voyiez ici aucune ligne de code, je pense n\u00e9anmoins que tout ce qui a \u00e9t\u00e9 dit ici rev\u00eat une grande importance pour \u00e9crire un code de qualit\u00e9 et expressif. <\/p>\n

Premier niveau de compr\u00e9hension : Pourquoi \u00e7a ne fonctionne pas ?<\/h4>\n

\nLes d\u00e9veloppeurs atteignent g\u00e9n\u00e9ralement ce niveau au d\u00e9but de leur carri\u00e8re, parfois m\u00eame sans aide ext\u00e9rieure - du moins, c'est ce que j'ai observ\u00e9. Imaginez que vous recevez un rapport de bug : une certaine fonction dans l'application ne fonctionne pas, il faut la r\u00e9parer. Comment allez-vous agir ?<\/p>\n

Le sch\u00e9ma standard ressemble \u00e0 ceci :<\/p>\n

    \n
  1. Trouver le morceau de code qui pose probl\u00e8me (comment cela se fait - c'est un sujet distinct, que j'aborde dans mon livre sur le code obsol\u00e8te)<\/li>\n
  2. Apporter des modifications \u00e0 ce morceau<\/li>\n
  3. S'assurer que le bug est corrig\u00e9 et qu'aucune erreur de r\u00e9gression n'est survenue<\/li>\n<\/ol>\n

    \nConcentrons-nous maintenant sur le deuxi\u00e8me point : les modifications du code. Il existe deux approches pour ce processus. La premi\u00e8re consiste \u00e0 comprendre exactement ce qui se passe dans le code actuel, identifier le bug et le corriger. La seconde est plus exp\u00e9rimentale : ajouter, par exemple, +1 dans une instruction conditionnelle ou une boucle, v\u00e9rifier si cette fonction fonctionne dans le sc\u00e9nario souhait\u00e9, puis essayer autre chose et ainsi de suite ind\u00e9finiment.<\/p>\n

    La premi\u00e8re approche est la correcte. Comme l'explique Steve McConnell dans son livre Code Complete (que je recommande d'ailleurs vivement), chaque fois que nous modifions le code, nous devons \u00eatre capables de pr\u00e9dire avec confiance comment cela affectera l'application. Je cite de m\u00e9moire, mais si le correctif ne fonctionne pas comme pr\u00e9vu, cela devrait beaucoup vous alerter et vous devriez remettre en question l'ensemble de votre plan d'action.<\/p>\n

    Pour r\u00e9sumer, afin de r\u00e9aliser un bon bugfix qui n'alt\u00e8re pas la qualit\u00e9 du code, il est essentiel de comprendre toute la structure du code ainsi que la source du probl\u00e8me sp\u00e9cifique.<\/p>\n

    Deuxi\u00e8me niveau de compr\u00e9hension : Pourquoi cela fonctionne-t-il ?<\/h4>\n

    \nCe niveau est beaucoup moins intuitif que le pr\u00e9c\u00e9dent. En tant que d\u00e9veloppeur d\u00e9butant, je l'ai compris gr\u00e2ce \u00e0 mon sup\u00e9rieur, et par la suite, j'ai souvent expliqu\u00e9 ce principe \u00e0 des novices.<\/p>\n

    Cette fois, imaginons que vous recevez deux rapports de bugs simultan\u00e9ment : le premier concerne le sc\u00e9nario A, le second le sc\u00e9nario B. Dans les deux cas, quelque chose ne va pas. Vous commencez donc par le premier bug. En vous basant sur les principes que nous avons \u00e9tablis pour le premier niveau de compr\u00e9hension, vous vous plonger dans le code li\u00e9 au probl\u00e8me, d\u00e9couvrez pourquoi il fait agir l'application de cette mani\u00e8re dans le sc\u00e9nario A, et y apportez des modifications raisonnables qui donnent exactement le r\u00e9sultat attendu. Tout se passe bien.<\/p>\n

    Ensuite, vous passez au sc\u00e9nario B. Vous r\u00e9p\u00e9tez le sc\u00e9nario en essayant de provoquer l'erreur, mais \u2014 surprise ! \u2014 tout fonctionne maintenant comme pr\u00e9vu. Pour confirmer votre hypoth\u00e8se, vous annulez les modifications apport\u00e9es lors du traitement du bug A, et le bug B r\u00e9appara\u00eet. Votre correctif a r\u00e9solu les deux probl\u00e8mes. Quelle chance !<\/p>\n

    Vous ne vous y attendiez pas du tout. Vous avez trouv\u00e9 un moyen de corriger l'erreur du sc\u00e9nario A et vous ne savez pas pourquoi cela a fonctionn\u00e9 pour le sc\u00e9nario B. \u00c0 ce stade, il y a une forte tentation de penser que les deux t\u00e2ches ont \u00e9t\u00e9 accomplies avec succ\u00e8s. C'est logique : l'id\u00e9e \u00e9tait de corriger les erreurs, n'est-ce pas ? Mais le travail n'est pas encore termin\u00e9 : vous devez encore comprendre pourquoi vos actions ont corrig\u00e9 l'erreur dans le sc\u00e9nario B. Pourquoi ? Parce qu'il fonctionne peut-\u00eatre sur des principes incorrects, et vous devrez alors chercher une autre solution. Voici quelques exemples de tels cas :<\/p>\n