Les essais logiciels qui m’ont façonné

 (refactoringenglish.com)
74 points par GN⁺ 2025-10-02 | 3 commentaires | Partager sur WhatsApp
  • Bien que j’aie lu des milliers de billets de blog sur le logiciel en 20 ans, seuls quelques essais ont fondamentalement changé ma manière de penser ; voici 10 essais essentiels, du « Joel Test » de Joel Spolsky à la défense du JavaScript pur par Julia Evans
  • Le « Joel Test » de Joel Spolsky propose 12 questions pour évaluer si un employeur respecte ses développeurs, en vérifiant s’il donne la priorité à leur temps et à leur concentration via la gestion de source, les builds quotidiens et la correction prioritaire des bugs, entre autres
  • « Parse, don't validate » d’Alexis King présente une technique consistant à convertir les données dans de nouveaux types lors de leur validation, montrant comment le système de types peut contribuer à améliorer la sécurité et la fiabilité d’une application
  • « No Silver Bullet » de Fred Brooks distingue le travail logiciel entre complexité essentielle et complexité accidentelle, et soutient que les progrès des outils et du matériel ne peuvent pas apporter un gain de productivité de 10x, même si l’IA vient bousculer cette théorie
  • L’essai de Julia Evans sur le JavaScript pur lui a fait réaliser que le JavaScript ES2018 seul suffit, même sans framework ; depuis 2020, il n’intègre plus de framework JavaScript ni d’étape de build dans aucun projet

Le « Joel Test » de Joel Spolsky (2000)

  • Joel Spolsky est le plus grand blogueur logiciel de tous les temps, et ses essais ont profondément influencé l’approche de l’auteur vis-à-vis du logiciel
  • Le « Joel Test » est un ensemble de 12 questions destiné à évaluer dans quelle mesure un employeur investit réellement dans son équipe logicielle

  • Liste des 12 questions

    • Utilisez-vous un système de gestion de source ?
    • Pouvez-vous faire un build en une seule étape ?
    • Faites-vous des builds quotidiens ?
    • Disposez-vous d’une base de données de bugs ?
    • Corrigez-vous les bugs avant d’écrire du nouveau code ?
    • Avez-vous un planning à jour ?
    • Avez-vous des spécifications ?
    • Les programmeurs disposent-ils d’un environnement de travail calme ?
    • Utilisez-vous les meilleurs outils que l’argent peut acheter ?
    • Avez-vous des testeurs ?
    • Les nouveaux candidats écrivent-ils du code pendant l’entretien ?
    • Faites-vous des tests d’utilisabilité dans le couloir ?

  • Message principal

    • Certaines questions ont vieilli, mais ce n’est pas la question elle-même qui compte : c’est le méta-message de la question
    • Ce que Joel demande en réalité, c’est : respectez-vous les développeurs ?
    • Toutes les questions servent à évaluer si l’employeur privilégie le temps et la concentration des développeurs plutôt que des bureaux bon marché ou des délais à court terme
    • Le texte a été publié au sommet de la bulle Internet, à une époque où les développeurs expérimentés étaient une ressource précieuse, même si tout le monde ne s’en rendait pas encore compte
    • Le blog de Joel présentait toujours les programmeurs comme des génies rares et délicats, que les employeurs devaient rechercher et chérir
    • Tout au long de sa carrière, l’auteur a cherché des employeurs obtenant un bon score au Joel Test, et remercie Joel de lui avoir fourni cette grille de lecture

« Parse, don't validate » d’Alexis King (2019)

  • C’est un essai sur l’usage du système de types de Haskell, mais il a profondément changé sa manière de penser le logiciel, même sans s’intéresser aux systèmes de types ni à Haskell
  • La technique d’Alexis peut être utilisée dans tous les langages à typage statique comme Go, C++ ou Rust

  • Concept clé

    • Chaque fois que l’on valide des données, il faut les convertir dans un nouveau type
    • Exemple : si un nom d’utilisateur doit être limité à 20 caractères alphanumériques maximum, la solution naïve consiste à écrire une fonction validateUsername(username string) error

  • Le problème

    • Le code est dangereux par défaut
    • Comme il faut valider chaque nom d’utilisateur reçu, il est facile de créer par erreur un chemin de code qui traite un nom d’utilisateur sans validation
    • Si un utilisateur malveillant repère cette erreur, il peut injecter du code malveillant dans le champ du nom d’utilisateur ou le remplir avec des milliards de caractères afin d’épuiser les ressources du serveur

  • La solution d’Alexis

    • Utiliser une fonction parseUsername(raw string) (Username, error)
    • Dans le reste du code, utiliser un type personnalisé Username au lieu d’une string appelée « username »
    • La seule fonction capable de créer un Username est parseUsername, qui applique les règles de validation avant de renvoyer une instance de Username
    • Si l’on a une instance de Username, elle doit contenir un nom d’utilisateur valide
    • Les entrées non fiables étant toujours des string, il est impossible de passer une string à une fonction qui attend un Username

  • Impact

    • Avant cet essai, il pensait que les systèmes de types étaient surtout une distraction amusante pour nerds des langages
    • « Parse, don't validate » lui a ouvert les yeux sur la valeur des fonctionnalités du compilateur pour améliorer la sécurité et la fiabilité des applications

« No Silver Bullet » de Fred Brooks (1986)

  • Il a lu The Mythical Man-Month de Fred Brooks à l’université
  • Un recueil d’essais sur l’ingénierie logicielle fondé sur son expérience à la tête du projet OS/360 d’IBM

  • Complexité essentielle et complexité accidentelle

    • Complexité essentielle : le travail qu’il faut absolument accomplir, quels que soient les outils ou le matériel
      • Exemple : dans un logiciel qui calcule les primes des commerciaux, il faut définir la formule de prime et couvrir tous les cas limites
      • Que l’on utilise un superordinateur à 5 milliards de dollars ou un microcontrôleur à 1 dollar, c’est le même travail
    • Complexité accidentelle : tout le reste
      • Gérer des fuites mémoire, attendre la compilation du code, comprendre comment utiliser une bibliothèque tierce
      • Plus les outils et les ressources matérielles sont bons, moins on passe de temps sur la complexité accidentelle

  • La conclusion de Brooks

    • Les progrès des outils ou du matériel ne peuvent pas produire un gain de productivité de 10x pour les développeurs
    • Même en ramenant à zéro le temps consacré à toutes les activités accidentelles, on ne peut pas obtenir un tel saut à l’échelle à moins qu’elles ne représentent plus de 9/10 de l’effort total

  • Cas d’application

    • Tout au long de sa carrière, il a vu des gens essayer d’éliminer les programmeurs du logiciel
    • Les plateformes no-code ont fait parler d’elles en promettant aux non-programmeurs toute la puissance d’un développeur web expérimenté
    • L’essai de Brooks l’a toujours rassuré sur le fait que les plateformes à la mode du moment ne peuvent pas remplacer les développeurs
    • Ces plateformes se concentrent sur la complexité accidentelle, pas sur la complexité essentielle
    • Même si une plateforme pouvait produire comme par magie du code fonctionnel à partir de spécifications, il faudrait toujours quelqu’un pour écrire ces spécifications

  • L’impact de l’IA

    • L’IA moderne met un sérieux grain de sable dans la théorie de Brooks
    • L’IA réduit réellement la complexité essentielle
    • Si l’on donne à une IA des spécifications incomplètes ou contradictoires, elle peut combler les trous en s’inspirant de spécifications similaires
    • Même si l’IA élimine la programmation telle qu’on la connaît, l’essai de Brooks laisse espérer qu’à un certain niveau d’abstraction, il faudra toujours quelqu’un pour gérer la complexité essentielle

« Choices » de Joel Spolsky (2000)

  • Il était difficile de ne choisir qu’un seul essai de Joel Spolsky, alors il en a retenu deux
  • « Choices » traite de la création d’interfaces utilisateur et du coût subtil qu’implique le fait de donner du pouvoir aux utilisateurs

  • Message principal

    • Chaque option proposée revient à demander à l’utilisateur de prendre une décision
    • Cela signifie que l’utilisateur doit réfléchir à quelque chose et trancher
    • Ce n’est pas forcément mauvais, mais en général, il faut chercher à minimiser le nombre de décisions que les gens doivent prendre

  • Exemple de Windows 98

    • Joel partage une boîte de dialogue absurde affichée dans Windows 98 lors d’une recherche dans la documentation d’aide
    • Cette boîte de dialogue le mettait en colère parce qu’elle :
      • interrompt l’utilisateur alors qu’il essaie d’obtenir de l’aide
      • lui demande de prendre une décision non éclairée sur l’optimisation d’une base de données
      • montre que Windows évite de prendre la décision et la refourgue à l’utilisateur

  • Champ d’application

    • L’essai de Joel porte sur les interfaces graphiques, mais l’auteur y pense partout où quelqu’un peut être confronté à son code, y compris en ligne de commande ou pour d’autres développeurs qui appellent les fonctions qu’il écrit
    • Peut-il prendre des décisions utiles à la place des utilisateurs, tout en leur laissant la maîtrise de ce qui les intéresse ?
    • L’essai de Joel l’a empêché d’innombrables fois de refiler à l’utilisateur des décisions qu’il pouvait prendre lui-même

« Application compatibility layers are there for the customer, not for the program » de Raymond Chen (2010)

  • Raymond Chen est l’un des développeurs ayant travaillé le plus longtemps au sein de l’équipe Microsoft Windows
  • Son blog contient des milliers d’histoires instructives et amusantes sur l’histoire de la programmation sous Windows

  • Exemple de demande client

    • Demande d’un client au sujet du mode de compatibilité Windows Vista :
      • Un programme conçu pour Windows XP et Windows Server 2003 rencontre des difficultés sur Windows Vista
      • S’il est configuré en mode de compatibilité Windows XP, il fonctionne bien sur Vista
      • Question : quels changements apporter à l’installateur pour qu’il s’exécute automatiquement en mode de compatibilité XP sur Vista ?

  • L’analogie de Raymond

    • « D’habitude, je jette mes déchets sur le trottoir devant l’animalerie, et chaque matin, quand le magasin ouvre, quelqu’un balaie les déchets et les met à la poubelle. Mais l’animalerie n’ouvre pas le dimanche, donc le dimanche, les déchets restent là. Comment faire pour que l’animalerie ouvre aussi le dimanche ? »

  • La leçon

    • L’analogie était si drôle que je ne me suis rendu compte que bien plus tard que Raymond avait tort
    • Il tourne en dérision le péché des développeurs qui s’attendent à ce que Windows ne casse pas leurs applications après une seule release
    • Je ne suis pas d’accord avec les détails, mais les textes de Raymond sont si drôles et incisifs qu’on passe outre leurs défauts
    • Excellente leçon sur l’influence du comportement utilisateur :
      • Si vous voulez amener les utilisateurs à faire quelque chose qui vous aide, vous devez réfléchir avec soin au chemin de moindre résistance de leur point de vue
      • Si vous leur montrez que jeter les déchets sur le trottoir résout entièrement leur problème, ils continueront à le faire

« Don’t Put Logic in Tests » d’Erik Kuefler (2014)

  • J’ai toujours aimé les tests unitaires et j’étais très fier de mon code de test
  • J’ai été choqué quand cet essai est apparu dans mes toilettes et a révélé que j’écrivais des tests catastrophiques depuis toute ma carrière

  • Exemple de test problématique

    @Test public void shouldNavigateToPhotosPage() {  
  String baseUrl = "http://plus.google.com/";;  
  Navigator nav = new Navigator(baseUrl);  
  nav.goToPhotosPage();  
  assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl());  
}

  • Les problèmes découverts

    • La première fois que j’ai lu cet essai, je me suis dit : « Mais c’est exactement comme ça que j’écris mes tests unitaires ! »
    • Pourquoi dupliquer la chaîne http://plus.google.com/ à deux endroits ? Créez une source unique de vérité, comme dans le code de production
    • J’ai toujours ajouté des fonctions helper, des variables et des boucles pour éliminer la duplication dans les tests
    • Le problème, c’est que cette approche masque des bugs subtils : en réalité, l’assertion porte sur http://plus.google.com//u/0/photos (avec deux slashs)

  • La prise de conscience

    • L’essai d’Erik montre qu’il ne faut pas traiter le code de test comme du code de production
    • Les deux ont des objectifs et des contraintes complètement différents
    • Un bon code de test doit avant tout être clair
    • Le code de test n’a pas son propre code de test ; la seule façon de vérifier sa justesse est donc de l’inspecter
    • Un test doit rendre éblouissamment évident au lecteur le comportement qu’il valide
    • Pour atteindre cet objectif, on peut tolérer de la duplication afin de réduire la complexité

« A little bit of plain Javascript can do a lot » de Julia Evans (2020)

  • En tant qu’ingénieur logiciel, je suis arrivé étonnamment tard sur le web
  • Pendant les dix premières années de ma carrière, je n’ai écrit du code que pour des applications desktop et des serveurs back-end
  • Jusqu’en 2017, je ne m’intéressais ni à HTML ni à JavaScript

  • Idées reçues sur les frameworks

    • Quand j’ai commencé sérieusement à apprendre le développement front-end, j’avais l’impression que JavaScript était un langage bancal bricolé en dix jours et que son comportement variait énormément selon les navigateurs
    • Pour écrire une application web, il fallait quelque chose de moderne et sophistiqué qui me protège de toute la bile et de tous les défauts de JavaScript
    • J’ai essayé des frameworks web populaires comme Angular, React et Vue
    • J’ai suffisamment appris Vue, mais j’ai quand même passé un temps fou sur des problèmes de dépendances et des pièges du framework
    • Malgré tout ce que ces frameworks front-end ont fait pour corriger JavaScript, la programmation web restait toujours aussi pénible

  • La prise de conscience apportée par l’essai de Julia

    • J’ai réalisé que j’étais tellement convaincu que JavaScript devait être réparé que je ne lui avais jamais vraiment laissé sa chance
    • Je travaillais sur un prototype de TinyPilot et je comptais implémenter l’interface web avec Vue
    • L’essai de Julia m’a inspiré à voir jusqu’où on pouvait aller avec du JavaScript pur
    • Sans framework, sans bibliothèque wrapper, sans build step, sans Node.js, juste du JavaScript ordinaire (ES2018)
    • Je m’attendais sans cesse à tomber sur un problème qui m’obligerait à passer à un framework ou à un builder, mais cela n’est jamais arrivé
    • Il y a bien eu quelques pièges liés à WebComponents, mais rien en comparaison de la souffrance que j’avais connue avec Vue et Angular

  • La liberté sans framework

    • J’adore être libéré des frameworks
    • Quand il y a une erreur à l’exécution, la stack trace n’est pas le mauvais rêve d’un code minifié, transformé et tree-shaké
    • Je peux déboguer mon code tel que je l’ai écrit
    • Mes préjugés sur JavaScript étaient faux
    • Le JavaScript moderne est plutôt bon, et il a absorbé beaucoup d’idées des bibliothèques wrapper au point qu’on n’a plus besoin de wrapper
    • Les navigateurs se sont ressaisis pour garantir un comportement cohérent entre plateformes et appareils
    • Depuis 2020, je n’ai intégré aucun framework JavaScript ni aucun build step à mes nouveaux projets, et je ne l’ai jamais regretté
    • Avec du JavaScript pur, on obtient 90 % des avantages d’un framework pour 5 % des maux de tête

« Choose Boring Technology » de Dan McKinley (2015)

  • Cet essai est étrange à inclure dans cette liste parce que je ne l’ai en fait jamais lu
  • Des gens l’ont cité, et une fois l’idée comprise, elle m’a paru si intuitive que je n’ai jamais ressenti le besoin de le lire

  • Idée centrale

    • Quand on démarre un nouveau projet, on est tenté d’utiliser une technologie de pointe très en vue
    • Google a annoncé une nouvelle base de données capable de monter jusqu’à l’exaoctet, 40 % plus rapide que Postgres et 20 % moins chère
    • Utiliser Postgres quand cette nouvelle alternative sexy est juste là paraît idiot
    • En réalité, les nouvelles technologies ont des bugs et des faiblesses, mais ce n’est pas encore évident
    • Et quand on s’y heurte, on est démuni
    • Postgres a ses défauts, mais après 30 ans d’usage sur le terrain, il existe des solutions éprouvées à pratiquement tous les problèmes auxquels vous avez des chances d’être confronté

  • Le concept de jetons d’innovation

    • Dan reconnaît qu’il faut parfois utiliser de nouvelles technologies, mais seulement de façon stratégique et en quantité limitée
    • Chaque entreprise reçoit trois “jetons d’innovation” à dépenser
    • Si vous voulez cette nouvelle base de données tape-à-l’œil, vous devez dépenser l’un de vos jetons
    • L’essai de Dan s’articule naturellement avec celui de Julia
    • J’aurais aimé lire l’un ou l’autre avant de gaspiller tout ce temps avec des frameworks front-end

« I’ve locked myself out of my digital life » de Terence Eden (2022)

  • Terence Eden est un blogueur tech à la fois drôle et éclectique
  • Il publie plusieurs nouveaux billets chaque semaine, mais celui qui a eu le plus d’impact est « Je me suis exclu moi-même de ma vie numérique »

  • Scénario catastrophe

    • Simulation de ce qui se passerait si la foudre frappait la maison de Terence et détruisait tous ses biens
    • Tous les mots de passe sont stockés dans un gestionnaire de mots de passe
    • Si tous les appareils sont détruits, il devient impossible d’accéder au gestionnaire de mots de passe
    • Impossible de remplacer cela par des passkeys matérielles, puisqu’elles se trouvaient elles aussi à la maison

  • Prise de conscience

    • L’auteur avait l’impression d’être plutôt en sécurité sur le plan des données, avec tout stocké sur des disques redondants et des sauvegardes hors site réparties sur trois continents chez deux fournisseurs
    • Le texte de Terence l’a amené à réfléchir aux nombreuses menaces crédibles capables de faire disparaître tous les appareils en même temps : incendie, inondation, surtension électrique, enquête criminelle
    • Comme toutes les données sont chiffrées par des mots de passe conservés dans sa tête, il faut aussi ajouter à la liste l’amnésie, l’incapacité et la mort

  • Le problème des services en ligne

    • Les services en ligne sont peu robustes quand il s’agit d’aider leurs utilisateurs à se remettre d’une catastrophe
    • Beaucoup de services partent du principe qu’il est impossible de perdre son téléphone, sans parler du compte e-mail et de tous les appareils numériques que l’on possède

  • Impact

    • Depuis la lecture de l’essai de Terence, il réfléchit davantage aux services et appareils réellement critiques, et à la manière de récupérer l’accès dans le scénario décrit par Terence
    • Lorsqu’il a acheté son ordinateur portable suivant, il l’a configuré à la bibliothèque pour vérifier s’il pouvait récupérer l’accès à son gestionnaire de mots de passe et à ses comptes importants sans aucun appareil resté à la maison
    • Il pourrait encore mieux se préparer à une catastrophe numérique, mais le texte de Terence continue de résonner dans sa tête chaque fois qu’il pense à la manière de sécuriser ses appareils et ses données
    • Que se passerait-il si tout était soudainement détruit ?

Bonus : « parsing user input » de Brad Fitzpatrick (2009)

  • Techniquement, ce n’est pas un essai, mais il pense constamment à cette citation tirée d’une interview sur le logiciel
  • Il a lu Coders at Work après la critique dithyrambique publiée par Joel Spolsky en 2009
  • Un recueil d’entretiens avec des programmeurs à succès

  • Citation de Brad Fitzpatrick

    • Brad Fitzpatrick, créateur de LiveJournal et de Memcached, fait partie des personnes interviewées
    • Il avait alors 28 ans, le plus jeune programmeur du livre, et aussi le plus grossier et le plus drôle
    • À une question sur l’éthique en génie logiciel, il répond par une tirade passionnée sur la validation des entrées :
      • « J’aimerais que tout le monde permette systématiquement de saisir des espaces ou des tirets dans les formulaires de carte bancaire. Les ordinateurs savent très bien supprimer ce genre de choses. Ne me dites pas comment formater mon numéro. »

  • Application

    • Chaque fois qu’il essaie de coller un numéro de téléphone dans un formulaire web, cette citation lui revient en tête
    • Il râle quand les parenthèses ou les espaces ne sont pas autorisés, ou pire, quand le logiciel tronque le numéro à cause des parenthèses puis se plaint qu’elles ne sont pas autorisées
    • Chaque fois qu’il crée un champ de saisie dans un logiciel et réfléchit aux caractères inattendus, il entend Brad Fitzpatrick dire « Les ordinateurs savent très bien supprimer ce genre de choses. »

À lire aussi

3 commentaires

 
shakespeares 2025-10-07

C’est grâce à l’histoire que le présent existe.
 
GN⁺ 2025-10-02
Avis Hacker News

  • Après avoir lu l’article « I've locked myself out of my digital life », j’ai eu l’impression qu’il exprimait très bien une inquiétude que j’avais sans vraiment réussir à la formuler
    Dans le monde analogique, je pourrais sans doute convaincre un humain de qui je suis, faire vérifier mon identité et retrouver l’accès à mon compte, mais face aux algorithmes impitoyables du monde numérique, sans justificatifs d’authentification, supplier ne sert à rien
    Même l’entreprise qui fournit mon gestionnaire de mots de passe n’a pas le droit d’accéder à mes mots de passe
    Il n’y a même personne à convaincre, seul le code fait loi
    Je pense que tout le monde devrait comprendre ce problème avant de défendre la suppression des interactions en face à face dans tous les processus
    Dans l’article, cela peut sembler être un cas rare, mais c’est quelque chose qui peut tout à fait arriver lors d’une catastrophe naturelle ou d’un vol
    Article lié : https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my-digital-life/

    • Je pense qu’en réalité, peu de gens soutiennent ce genre d’automatisation extrême ou la réduction des interactions humaines
      Et ce n’est pas un problème propre à l’IA : les logiciels fondés sur des règles posent exactement le même souci
      Dans l’Union européenne (UE), la loi garantit le droit de contester toute décision devant un être humain

  • Grug Brained Developer est un texte qui me reste toujours en tête, mais il n’était pas dans la liste
    En fait, c’est peut-être justement parce que j’étais déjà d’accord avec ce qu’il disait qu’il m’a surtout marqué, plutôt que de transformer ma façon de penser
    Référence : https://grugbrain.dev/

    • Parmi tout ça, j’aime vraiment beaucoup le passage sur « la meilleure sensation, c’est enfin d’enfermer le démon de la complexité dans un cristal correctement taillé »

    • Je suis bilingue et l’anglais est ma deuxième langue, donc les textes écrits dans le style grug brain sont assez difficiles à lire et à comprendre pour moi
      Je ne sais même pas ce que veut dire le mot « grug »
      Malgré tout, j’aime bien lire ce blog

  • Je ne suis pas d’accord avec la conclusion de Fred Brooks dans « No Silver Bullet »
    Je ne partage pas l’idée selon laquelle l’IA récente aurait réduit la complexité essentielle au point d’invalider la thèse de Brooks
    Une IA peut peut-être combler automatiquement des spécifications incomplètes ou contradictoires en s’appuyant sur des cas similaires, mais la complexité essentielle n’est toujours pas suffisamment résolue par l’IA, et je pense que cela restera impossible à l’avenir
    Mon analyse détaillée sur le sujet est ici : https://smartmic.bearblog.dev/no-ai-silver-bullet/

    • Merci de l’avoir lu et d’avoir partagé mon texte
      Comme tu le soulignes dans ton commentaire, je suis d’accord sur le fait que les LLM ne peuvent pas faire disparaître complètement la complexité essentielle
      En revanche, je pense qu’ils peuvent la réduire dans une certaine mesure
      Par exemple, j’ai demandé à Claude 4.1 Opus de définir un langage spécifique à un domaine pour générer des images par ordinateur
      Je lui ai seulement donné les exigences, en laissant volontairement certains détails flous, et le LLM a tout de même rédigé une spécification
      Dans ce genre de cas, je suis convaincu que le LLM a réduit la complexité essentielle
      Je pourrais bien sûr définir moi-même quelque chose de haute qualité à partir de zéro, mais si le résultat produit par le LLM est suffisant, il y a moins de raison d’investir des efforts supplémentaires pour améliorer encore la qualité
      À l’origine, je pensais ne pas avoir vraiment besoin des LLM parce que je code mieux moi-même et que j’y prends plus de plaisir, mais après les avoir utilisés, j’ai constaté qu’ils prennent en charge une part significative de la complexité essentielle dans tout ce qui ne mérite pas forcément mon temps et mon énergie
      Exemple : https://kagi.com/assistant/1b8324a2-ae54-4a1b-9c69-51d76fc5c7d1

    • La complexité que l’IA réduit, au fond, ce n’est que la charge cognitive de la personne qui écrit le code
      La « complexité non essentielle » dont parlait Brooks reste presque entièrement présente dans le code lui-même
      Au final, cette charge est simplement transférée à la personne qui devra lire le code
      C’est un peu comme enfiler un exosquelette pour poser un objet lourd sur une étagère, puis demander à un collègue de le repeindre joliment

  • L’essai « Parse, don't validate » est à mes yeux un classique absolu
    En revanche, j’ai du mal à être d’accord avec la phrase « Don't put logic in tests »
    Dans l’exemple, le problème vient du fait qu’on devrait utiliser un type URI au lieu d’une chaîne de caractères, et je pense que le code de test doit aussi être considéré comme du code de production, puisqu’il a lui aussi un impact sur la réussite ou l’échec d’un déploiement
    Quoi qu’il en soit, ce sont des discussions qui valent largement la peine d’être examinées de près pour voir si elles peuvent s’appliquer à son propre cas

    • Moi aussi, je trouve étonnant que « Parse, don't validate » soit si peu connu
      Dans mon entourage, la plupart des gens travaillent en Go, Python ou C++, donc j’ai l’impression que ce texte est surtout célèbre du côté des langages fonctionnels
      Je pense que la critique adressée à l’exemple de « Don't put logic in tests » est pertinente
      On pourrait sans doute remplacer l’exemple par un meilleur cas, mais l’idée essentielle reste que même une simple concaténation de chaînes peut ajouter de la complexité aux tests et conduire à laisser passer des bugs

    • Personnellement, je trouve attrayante la philosophie qui consiste à ne pas mettre (trop) de logique dans les tests
      J’ai plusieurs fois connu des faux positifs provoqués par des bugs dans le code de test, ce qui m’a rendu méfiant sur ce point
      Je ne pense pas qu’on doive ressentir le besoin d’écrire des « tests pour les tests »
      En pratique, ce genre de cas reste rare, mais dernièrement, les mauvais tests générés par les LLM semblent devenir la norme, ce qui aggrave encore le problème indépendamment de cette philosophie

  • Je recommande les documents d’enquête et d’analyse de Nancy Leveson sur l’accident du Therac-25

  • Pour moi, mon texte préféré dans ce domaine est « The Parable of the Two Programmers » de Neil W. Rickert
    C’est une histoire qui résume avec concision la vie et les défis des programmeurs
    https://c00kiemon5ter.github.io/code/philosophy/2011/10/30/Tale-of-two-Programmers.html

    • Je connais bien Neil, car j’ai souvent échangé avec lui pendant des années dans le groupe de discussion Usenet comp.ai.philosophy
      Le ton et le contenu du texte sont vraiment tout à fait dans son style

    • Ce texte est vraiment excellent

  • Pour moi, ce texte a marqué un tournant
    https://stevemcconnell.com/articles/software-quality-at-top-speed/

    McConnell n’est pas particulièrement connu ici

    • Merci pour le partage !
      C’est la première fois que je lis ce texte, mais j’ai été profondément marqué au début de ma carrière par la lecture de Code Complete
      Je l’ai gardé dans ma bibliothèque et, même en ne le relisant que quelques fois, je me suis toujours dit : « C’est vraiment excellent ! Il faut absolument que je le relise »
      Cela faisait un moment que je n’avais plus entendu parler de McConnell, et je me demandais pourquoi, alors que d’autres auteurs de la même époque comme Kent Beck, Martin Fowler ou Ward Cunningham ont continué à écrire même après avoir perdu en popularité dans les années 2000, McConnell, lui, était resté silencieux
      J’ai été discrètement choqué d’apprendre qu’il avait quitté le logiciel pour devenir conseiller financier
      https://raindogllc.com/steve-mcconnell-investment-advisor/

  • Ce n’est peut-être pas un essai sur le logiciel au sens strict, mais le billet de blog « Ban on Imports » de Gilad Bracha a complètement changé ma vision des systèmes de modules
    Il insiste sur le fait que les import/export reviennent à l’état global, et qu’ils héritent donc de tous les problèmes de l’état global
    Depuis, j’accorde beaucoup plus de valeur au concept d’injection de dépendances
    https://gbracha.blogspot.com/2009/06/ban-on-imports.html

  • On peut peut-être difficilement le classer strictement comme essai logiciel, mais « Don't Call Yourself A Programmer, And Other Career Advice » de Patrick McKenzie est un véritable trésor
    https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

  • Comme quelqu’un qui s’intéresse beaucoup aux langages de programmation, le texte « slumming with basic programmers » m’est beaucoup resté en tête
    https://prog21.dadgum.com/21.html
 
secret3056 2025-10-02

Je suis tout à fait d’accord pour le parsing des entrées utilisateur.
Dans quel genre d’environnement travaillent donc la plupart des développeurs qui implémentent une fonctionnalité de saisie de numéro de téléphone alternatif, pour avoir si peur d’appeler deux fois replace() sur une chaîne de caractères ?