Les débats de développeur(euse)s sont intenses

En dehors du titre, le générique masculin est utilisé sans aucune discrimination et uniquement dans le but d'alléger le texte.

Les débats de développeur(euse)s sont intenses

Les débats de développeurs sont d’une intensité folle. C’est pas des simples discussions. C’est des débats politiques avec des enjeux d’état. C’est sérieux, souvent enrichissant, mais toujours beaucoup trop militant.



Le code coverage

Y’a pas longtemps, avant tout ce bordel de virus de merde, je me suis retrouvé au milieu d’un débat. Et le sujet en question c’était l’indémodable code coverage. Un grand clasico.

Le débat est simple. Pour les tests unitaires, faut-il forcer un code coverage de 100% ou non ? Quelqu’un a posé la question innocemment un matin pendant le stand-up. Le ton est monté instantanément. Une ligne a été tracée dans le sable. Deux camps radicalement opposés se sont formés.



débats


À ma droite, le camp du non. Les arguments sont bons. Y’en a d’autres, mais par souci de longueur on va évoquer seulement les deux principaux.

  • Beaucoup de tests vont être faits “pour remplir” et arriver aux chiffres fatidiques. En ne forçant pas le 100%, on peut se concentrer sur les tests qui comptent vraiment. Travailler moins pour gagner plus.
  • Certaines parties de ton app n’ont juste pas besoin de tests unitaires. Comme par exemple le lancement d’un serveur web express en Node. Et c’est super chiant de mocker plein de merde juste pour arriver à 100%.

À ma gauche, le camp du oui. Eux aussi ont plein d’arguments solides. Les deux principaux sont les suivants.

  • À 100%, on oblige le code à être pensé pour être plus testable, plus modulaire et donc plus maintenable. Et donc tout simplement, ça augmente la qualité de tout le projet.
  • En faisant passer la machine partout, le développeur va détecter des bugs insoupçonnés avant de les voir apparaître en prod. Tu rends clairs les moindres recoins obscurs de ton application.

Après un débat digne du second tour de la présidentielle, cette histoire s’est finie que le lead tech a posé un veto et forcé le 100%. Ça tombait bien, je suis dans le camp des 100% ! Et je t’attends dans les commentaires si t’es pas d’accord avec moi.



POO contre programmation fonctionnelle

Ce débat est aussi un classique. Quel paradigme de programmation est le meilleur ? L’orienté objet ou le fonctionnel ? Les gens ADORENT parler de ça. J’ai toujours trouvé que c’était une perte de temps totale. Ça ne fait rien avancer et c’est chiant à mourir.



dodo


Mais allez, parlons rapidement de ce débat. Il y a quand même deux trois trucs intéressants à retenir dans tout ce bordel. La discussion tourne presque à chaque fois autour du fait que la programmation fonctionnelle gagne en popularité et tend à prendre de plus en plus de place.

Ceux qui détestent l’orienté objet en parlent beaucoup. L’article que je te mets là est super intéressant, mais c’est une lecture de 30 min. Le dev derrière tout ça est très intense. Il chie sur la POO pendant 30 min non-stop.

En résumé :

  • L’orienté objet serait juste trop compliqué pour pas grand-chose.
  • Énormément de temps serait perdu à réfléchir à de l’abstraction et des design pattern, au lieu de régler les vrais problèmes.
  • Les langages POO seraient moins adaptés à des besoins forts en concurrence à comparer au fonctionnel.

Mon avis là-dessus c’est que, comme toujours en informatique, ça dépend ! Ça dépend du besoin, du projet et de ton équipe. Et puis surtout ça dépend du langage dans lequel ton entreprise est la plus à l’aise.

Enfin de plus en plus de langage permettent d’utiliser plus ou moins les deux paradigmes. Bref, c’est pas le débat le plus fifou d’aujourd’hui.



Le meilleur IDE

Alors celui-là par contre est très drôle. Il fait pas avancer grand-chose non plus, mais on rigole. Quel est le meilleur éditeur de code ? Cette question déclenche des coups d’état !

Il y a bien longtemps, dans une galaxie lointaine, très lointaine, je bossais en permanence avec trois autres dev. Ces trois devs utilisaient tous SublimeText. Pas moi. Moi, je suis team Visual Studio Code. Ils ont essayé de me convertir pendant un moment, sans succès.

Et un jour, la décision fut prise qu’une machine virtuelle commune allait être faite. Un environnement de travail commun créé via Vagrant et provisionné avec Ansible. De base, SublimeText sera installé, mais pas Visual Studio Code !

Apparemment, Visual Studio Code c’était pas assez bien. J’étais vraiment choqué. Quelle honte. Quelle indignité !



débats


Bon, à force de chialer, j’ai pu moi-même intégrer VSC au playbook Ansible. Mais pas avant un énième débat. Et ce qui est drôle avec ce débat c’est que les arguments sont tous bidon. C’est de la religion pure. Les éditeurs se valent tous plus ou moins.

  • Toutes les features sont reproduisibles d’un éditeur à un autre, avec ou sans plugin.
  • L’écrasante majorité est multiplateforme et multilangages
  • Les performances entre les éditeurs se valent toutes
  • Même les shortcuts peuvent être transférés d’un IDE à un autre.

VSC à eu mauvaise réputation à un moment, niveau performance c’était problématique. Mais ça fait longtemps que c’est fini tout ça. Maintenant il est loin devant côté utilisation.

La seule exception je dirais c’est VIM. Je suis obligé d’avouer que les utilisateurs expérimentés de VIM sont plus rapides à manipuler du code. L’utilisateur de shortcut poussé et l’oubli de la souris sont redoutables. Ça boost la productivité. Le problème c’est le prix d’entrée dans VIM. Il faut apprendre, retenir les shortcuts et savoir utiliser vraiment VIM sans devenir fou. Faudrait que je m’y mette un jour, surtout que VIM existe dans VSC.



La guerre des langages

De loin le débat le plus virulent. Celui qui a fait le plus de victimes. Quel est le meilleur langage informatique ? Tout le monde s’accroche, on atteint des niveaux de pression critiques.

Tu te doutes bien que je vais pas te soûler avec tous les arguments de tous les langages. Ce débat est réservé aux gens qui n’ont toujours pas compris que les langages sont des outils. Et quand on leur dit que leurs langages ne conviennent pas au besoin, ça les rend fous.



fou


Je vais pas te refaire toute l’explication sur la religion chez les développeurs. Si le sujet t’intéresse, j’en ai dédié un article. Je t’invite aussi à aller voir les commentaires sur mon article sur PHP pour te rendre compte de l’intensité des devs sur ce débat. Mais en gros tu peux mettre fin au débat en avançant les points suivants.

  • Besoin de développement web ? Javascript et/ou PHP sont tes amis.
  • Besoin de serveur à fortes concurrences ? Go c’est vraiment pas mal.
  • Besoin de faire un jeux vidéo ? C++ est bien adapté.
  • Besoin de faire du machine learning ? Python est excellent.

Etc etc, tu vois où je veux en venir. Chaque langage est différent des autres dans ses principes fondamentaux et ses objectifs. Les comparer entre eux, c’est une perte de temps. Il suffit de savoir en quoi ils sont adaptés.

Bref, comme à chaque fois depuis le début de cet article. Mon avis sur les débats ne change pas. CA DÉPEND !



débats


HTML c’est de la programmation

Alors celui-là, c’est de loin le plus bizarre de tous. HTML c’est de la programmation ou pas ? T’en penses quoi toi pour de vrai ? Pour la plupart des développeurs, entendre quelqu’un dire qu’HTML est un langage de programmation, c’est un SCANDALE !



scandale


Cette question est devenue un débat et ce débat fait rage depuis des années. Des discours d’une violence rare ont été publiés partout. Que ça soit du côté du oui ou du côté du non, les militants ne font plus de diplomatie. Quels sont ces arguments ?

Du côté du oui

  • HTML est un langage de programmation déclaratif et non impératif. Mais ça reste un langage de programmation.
  • La programmation déclarative est une forme de programmation et donc HTML est un langage de programmation.
  • Dire que l’HTML n’est pas un langage de programmation viendrait d’une sorte d’élitisme de certains développeurs.

Du côté du non

  • Aucune condition, boucle, comparaison ou logique de façon général n’est applicable au HTML.
  • HTML est un langage de balisage (Markup), pas de programmation.
  • HTML n’est pas complet au sens de Turing. Ce ne donc pas un vrai langage de programmation

Mon avis là-dessus est vraiment partagé. Évidemment, j’ai envie d’être du côté du non. Pour moi, un langage c’est surtout manipulé de la logique. Mais en fait, ça dépend (oui encore) de ta définition de “langage de programmation”.

Si cette définition inclut les langages dits déclaratifs, alors HTML en fait partie. Je comprends que ce débat fait rage. Tout vient de la nuance sur la définition de langage. Il faudrait déjà se mettre d’accord sur ce point du coup.



Tabulation contre espace

On finit par le débat des débats. Le père de tout débat chez les développeurs. Un sujet qui fait hurler depuis presque 20 ans maintenant. Pour l’indentation de ton code, il vaut mieux utiliser les tabulations ou les espaces ?





Du côté espace :

  • Les espaces rendraient l’indentation plus consistante dans différentes configurations (OS, système de suivi, IDE)

Du côté tabulation

  • Les tabulations auraient été créées dans le but de l’indentation
  • Les espaces seraient imprécis dans le cas de l’indentation
  • Pour le même résultat, une tabulation utilise 1 bit quand 4 espaces utilisent 4 bit

Je vais être complètement honnête, je me suis jamais posé la question. J’ai toujours utilisé les tabulations de façon naturelle. Je pense que c’est une question de préférences personnelles.

Apparemment, tu ferais plus d’argent en utilisant les espaces. Personnellement, j’ai pas envie de me faire chier avec les espaces. J’ai pas non plus vu une vraie différence en utilisant l’un ou l’autre.

Par contre, quand je vois un dev taper sur sa barre espace quarante fois comme un malade pour indenter son code, ¸¸ça me donne envie d’hurler au secours.



jeanne


Épilogue

Bref, stoppez-vous. Tu te stop ! Vous êtes tous beaucoup trop intenses avec vos débats. Surtout quand on voit que la plupart sont totalement inutiles. Ce qui est important c’est d’en parler une bonne fois pour toutes dans ton équipe et que vous tombiez d’accord sur des guidelines. Sortie de ces guidelines, c’est juste de la politique.

Qui me parle ?

jesuisundev
Je suis un dev. En ce moment je suis Backend Développeur / DevOps à Montréal. Le dev est l'une de mes passions et j'écris comme je parle. Je continue à te parler quotidiennement sur mon Twitter. Tu peux m'insulter à cet e-mail ou le faire directement dans les commentaires juste en dessous. Y'a même une newsletter !

21 commentaires sur “Les débats de développeur(euse)s sont intenses”

  1. En vrai osef des tab/espaces. N’importe qu’elle IDE digne de ce nom permet de convertir une tab en un nombre défini d’espace. Celui qui tape comme un malade 4 fois pour faire son indentation en espace est juste un mec utilisant sont IDE comme un bloc note.

    Pour les autres débat, le pire pour moi est celui de L’IDE. Il y aura toujours un chef pour te dire qu’il faut rationaliser les IDE. Alors qu’a mon sens tant que le dev est plus productif avec un IDE et sait comment le configurer pour respecter les guideline du projet, imposer un IDE est un non sens complet.

  2. Ah le fameux débat sur quel IDE est le meilleur, j’en ai passé du temps en réunion pour rien parce que l’un de nos chefs voulait unifier l’utilisation de l’éditeur, pour au final se retrouver au point de départ avec l’utilisation de phpstorm et de visual studio code.
    Tu aurais pu également parler de la guerre des OS et encore pire les interminables discussions stériles entre le choix de la distribution Linux.
    Mon dernier débat interminable était le choix entre une architecture microservice et un monolithe.
    Comme tu l’as dit c’est parfois beaucoup trop militant !

  3. Pour espace vs. tabulation, il n’y a même pas de débat, il est absolument évident qu’il faut utiliser les espacs !

    > Les tabulations auraient été créées dans le but de l’indentation

    Oui, et il y a bien des gens qui ont inventés des soutiens gorges pour homme, c’est pas pour autant que c’est utile. D’autant plus que même ceux pour femmes on commence à se poser la question de leur utilité rélle, voir même de leur dangerosité. Ce qui me fait me poser la question, les tabulations ne sont-elles finalement pas dangereuse ?!

    > Les espaces seraient imprécis dans le cas de l’indentation

    Un espace fera toujours la même taille, il n’y a pas plus précis. On peut même indenter au caractère près pour s’aligner avec l’ouverture de parenthèse/accolade à la ligne supérieure, va faire ça avec tes tabulations… tu ne pourras pas, à moins de faire des tabs de la taille d’un caractère… A.K.A. DES ESPACES !

    > Pour le même résultat, une tabulation utilise 1 bit quand 4 espaces utilisent 4 bit

    Pour des langages compilés ça ne change rien au binaire en sortie. Et pour des langages interprétés ça n’est généralement pas significatif, puis il y a souvent du bytecode qui est généré aussi, auquel cet argument devient aussi caduque que pour du language compilé.
    Puis de toute façon il y a bien des gens qui utilisent des IDE codés en JS, donc on est plus à 3 bits près… 😛

    Voilà, je retourne dans ma grotte.

    1. P.S.: pas 1/4 bit/s mais 1/4 byte/s (octet/s en anglais…)
      P.P.S.: j’ai essayé d’utiliser la tabulation ici, pour être précis, mais rien n’y fait (on me souffle à l’oreillette que quand on doit/veut pouvoir éditer en ligne/web, les tabulations perdent la face/précision)

  4. T’as oublié le débat Javascript vs jQuery. Crois-moi, je le vois revenir régulièrement celui-là…

    Très bon article btw 😉
    D’ailleurs pour les tabs, je te rejoins : je les utilise “naturellement”.
    Bref, tous ces débats stériles c’est surtout du pur “qui pisse le plus loin” d’ego.

  5. Au risque de me faire taper, je suis plus team code coverage < 100%. Ça me parait utopique, voir un délire de perfectionniste. Mais la vérité, c'est juste que je n'ai jamais trouvé pertinent de le prioriser. Atteindre les 100% c'est généralement très chronophage et donc coûteux à l'échelle du projet. C'est quelque chose qu'il faut pouvoir prioriser en fonction de son budget et de son besoin. Donc comme le reste, ça dépend ! Vouloir les 100% à tout prix, je trouve que ça n'a pas de sens.
    Après voilà ce n'est que mon avis. Si certains d'entre vous ont des contres exemples, je suis preneur aussi.

  6. Très souvent l’origine de ces débats stérile c’est l’insécurité et ou la peur de l’inconfort.
    – Si mon langage est pas le meilleur , ca veux dire que j’ai pas fait le bon choix ?
    – Si mon ide est pas choisi , je vais devoir apprendre autre chose, je ne veux pas changer mes habitudes.
    – etc …
    Si on fait preuve d’un peu d’intelligence et qu’on passe au travers de tout ca en essayant de vraiment choisir les outils les plus adaptés à une situation donnée , on fini par toucher à plein de truc et à devenir un meilleur développeur.

  7. Ha tous ces fameux débats…
    Perso, je suis loin d’être un dev confirmé (Plutôt l’inverse, dev Junior en recherche de son premier poste ^^), mais j’ai déjà pu me forger un petit avis sur tous ces points…

    > Le code coverage 100% : De bons arguments des deux côtés, mais je pencherai plus sur le non. C’est beau d’avoir du 100% c’est sûr, est-ce que réellement TOUS les tests seront forcément utile ? Et pas une perte de temps qui pourrait être investie ailleurs ?

    > POO vs Fonctionnelle : Je dirais POO même si je suis loin d’en maîtriser tous les aspects. Mais est-ce qu’utiliser systématiquement la POO pour le moindre petit projet à faire est une bonne chose ? Peut-être pas…

    > Le meilleur IDE : Celui avec lequel tu es le plus a l’aise. Fin du débat. (Perso Visual Studio Code / VsCodium)

    > La guerre des langages : Moi j’aime bien PHP quand même… Ici tout n’est qu’une histoire de préférences personnelles je trouve… Peu de gens vont penser à quel langage serait mieux pour faire X projet, mais quel langage EUX préférerai utiliser pour ce dit projet….

    > HTML, de la programmation ? : Pour moi “programmer” quelque chose c’est faire marcher sa logique pour arriver à un résultat final. Pour moi HTML n’en est pas un mais est-ce qu- on s’en foutrait pas un peu de celle la ? Que tu trouves qu’HTML est de la “programmation” ou non, ce n’est pas ce qui va te faire écrire ton code ^^.

    > Tab vs espace : Au début j’étais team tab, puis je suis passé team espaces… Pour une raison assez simple : Quand tu veux copier/coller un bout de code (souvent de librairie css genre Bootstrap ou autre) c’est copié comme étant des espaces et pas des tabulations. Et pour peu que l’endroit en question d’où tu récupères ton bout de code n’as pas la même indentation que toi alors la accroche toi > Convertir tab en espace, changer la taille , reconvertir… Voilà, c’est juste pour ça…. Qu’est qu’on s’en fout qu’une tabulation soit juste de 1bit et 4 espaces 4x1bit ? Tu as des outils déjà tout fait pour alléger ton code, alors a quoi bon penser à ça lorsque tu codes ?

  8. C’es tassez drôle le débat tabs/spaces. En fait mon IDE indente tout seul donc en vrai je ne sais même pas ce que j’utilise, c’est un débat d’un autre temps j’ai l’impression

    1. La saisie dans l’IDE n’est qu’un aspect :
      – saisie IDE
      – saisie dans un autre outil (plateforme de code review par exemple)
      – navigation clavier dans le code (dans / hors IDE)
      – sélection du code (dans / hors IDE)
      – affichage dans les différents outils (IDE, outil WEB de gestion de source, de code review, d’analyse de qualité de code, …)
      J’en oublies probablement d’autre 🙂

      Ce blog éclaire pas mal sur les différents aspects (pro tab, je plaide coupable 😉 ) à prendre en compte sur la problématique des indentations : http://lea.verou.me/2012/01/why-tabs-are-clearly-superior/

      Sans parler des autres problèmes qui en découlent : choix par défaut des IDE (tab dans Eclipse vs space dans intellij) et du bordel après quand plusieurs dev font des mélanges improbable de types d’indentation (tout projet devrait avoir un .editorconfig et sa prise en compte dans l’IDE pour en finir pour commencer)

  9. La conclusion de cet article ne créer-t-elle pas deux nouveaux camps ?

    Le camps de ceux qui pensent qu’il faille débattre, ou non ^^

    Le camp du non-débat :
    – C’est important que chacun puisse être libre.
    – Finalement it depends toujours du use case.
    – Une irresponsabilité sociale qui par une lacune profonde de l’intérêt générale et donc quelque part une déshumanisation des relations préfèrent ne pas partager les bons usages quitte à ce que la culture commune se dégrade.

    Le camps du débat :
    – C’est important la liberté d’expression.
    – Finalement c’est une manière d’apprendre à se connaitre.
    – Une pulsion péremptoire d’imposer une vision uniforme qui inconsciemment renforce l’idée primitive d’une estime de soi comblée par le concept même d’avoir un levier quelconque sur autrui.

    qui débute et ton site m’apporte beaucoup pour mieux comprendre ce vaste univers de l’IT. Thanks a lot <3

  10. La seule chose qui m’a fait grincer des dents c’est de lire que python est le langage le plus adapté pour du ML, OMG ça mérite même pas débat c’est juste faux. C’est juste parce que les gens qui se disent des experts en IA sont pour la majorité des immenses quiches qui ne comprennent rien aux algo derrière les libs. La seule raison qui a fait que cette allocution innommable revient tout le temps c’est qu’il y a de très bonnes libs en python pour le ML ça c’est vrai. Parce que les gens qui faisaient de l’IA avant étaient sous Mathlab et qu’ils ont changé pour un truc qui lui ressemble avec autant de libs. PERIOD, mais un langage avec un semblant de multi threading comme celui de python (vaste blague au passage) ne peut pas être qualifié comme le meilleur outil pour faire de l’IA. Impossible.

    PS: je suis doctorant dans un labo d’IA, vous avez le droit de penser ce que vous voulez, mais chez nous tous les candidats sérieux ont vite compris que le python, ça n’allait pas passer…

  11. De tous les points, celui qui me chiffonne le plus (les autres n’étant pour moi que des débats stériles, typiquement le gain de l’utilisation des espaces je ne le comprends juste pas), le “code coverage” ça me fait doucement sourire, le pire étant les tests automatisé de l’UI.
    Sur un projet d’une durée de deux ans on a été jusqu’à pousser les “test fonctionnels automatisés” d’interface utilisateur via sélénium, sur 3 navigateurs différents. A la moindre mise à jour de driver/navigateur, les tests se viandaient la gueule. A la fin, à minima 35% du temps de dev de tout le projet a été passé sur les tests automatisés.
    Une fois on a trouvé un bug…Je peux vous assurer qu’il n’aurait jamais coûté 35% du coût du projet.

    Sur les TU, la plupart du temps le coût d’une évolution mineure est moins chère que le coût des modifications des tests unitaires.
    Un coverage à 100% c’est bien pour les gars qui veulent afficher des chiffres sur un dashboard, ça n’a jamais garantie que les tests étaient bien branlés donc je me marre.
    Vous en connaissez beaucoup de dev qui font de la revue de code de tests unitaires ? J’espère que non sinon ton code tu le paies trois fois.
    Déjà que le test unitaire est là pour t’assurer que cela fonctionne et fonctionnera, mais qui s’assure que le test est bon ? Le même qui l’a écrit…
    Les TU sont là aussi pour se “rassurer” sur les capacités de l’équipe ou le degré de latitude.

    Enfin on est d’accord que tout ça dépend du projet et de l’impact financier d’un bug, d’une perte de données, d’une faille.
    Le coverage à 100% pour moi c’est de l’overengineering. A part cas préciser ci-dessus à fort risque de perte financière.

    Je vais me faire pourrir mais je vous aime quand même.

  12. Moi j’étais avec mes petites tabulations de codeur amateur, mais je voyais partout les pros code avec des espaces, je n’en voyais pas l’intérêt, mais l’idée de me conformer au plus grand nombre faisait son chemin…
    Et puis je faisais déjà mon CSS avec Stylus (donc identation obligatoire avec 2 espaces)…
    Et puis le code de mes .pgsql publié sur Github était dégeulasse avec des tabs…
    Du coup j’ai mis tous mes fichiers d’accords entre eux et je suis passé chez l’ennemi !

T'en penses quoi ?

Your email address will not be published. Required fields are marked *