Joe a travaillé sur un système financier vieux de plusieurs décennies, initialement construit avec Oracle Forms. Le système a évolué, passant à Java pour l'interface utilisateur tout en conservant la base de données Oracle et en s'appuyant fortement sur PL/SQL. Cette longue durée de vie a entraîné l'accumulation de "kruft", y compris des procédures obsolètes comme la fonction "BOB". La procédure "BOB", un simple wrapper d'instruction d'impression, a étonnamment persisté à travers de nombreuses mises à niveau et migrations du système. Son existence est antérieure à l'historique de contrôle de code source disponible, ce qui indique qu'elle est dans le code depuis plus de vingt ans. Malgré son manque d'utilisation, la fonction reste dans la base de code, un témoignage de sa longévité. L'auteur, Joe, s'émerveille de la survie de la procédure et de l'identité mystérieuse du développeur d'origine, également nommé Bob. Le code a été utilisé par de nombreuses entreprises pour gérer des prêts. L'article souligne l'impact durable de décisions de codage apparemment mineures au fil du temps. Joe reconnaît l'importance des moindres détails dans un logiciel qui a une si longue durée de vie.

"SQL Server Integration Services (SSIS) est l'outil ETL de Microsoft, présentant une interface visuelle pour la manipulation de données. Il permet aux utilisateurs de concevoir des flux de données, en intégrant des transformations et diverses opérations, éliminant ainsi le besoin de scripts complexes. Les capacités de SSIS s'étendent à la migration de données, à l'intégration de systèmes et même à l'extraction dans des feuilles de calcul Excel. De manière remarquable, SSIS permet d'exécuter du code .NET dans son environnement. Le texte met en évidence une implémentation problématique : une procédure stockée "déplacer fichier" dans SSIS. Cette procédure stockée utilise xp_cmdshell, une fonction potentiellement dangereuse qui permet à SQL Server d'exécuter des commandes shell. Cette procédure stockée utilise les commandes `mv` et `cp`, qui nécessitent l'installation de GNU Core Utils sous Windows, créant ainsi une dépendance non documentée. Puisque xp_cmdshell est généralement désactivé pour des raisons de sécurité, cette configuration présente un risque de sécurité important. La migration initiale vers le nouveau matériel a fait échouer cette approche, mettant en évidence ses limites. La tâche de transfert de fichiers plus appropriée devrait être utilisée dans les packages SSIS au lieu de cette méthode non sécurisée. Le texte se termine par une publicité pour une solution de gestion de packages."

Il existe une collection d'incidents où des entreprises testent en production, ce qui est une partie essentielle du processus de développement. Tester en production permet aux entreprises d'identifier les problèmes avant leurs clients, mais cela doit être fait d'une manière qui n'affecte pas les clients. Lorsque les tests en production tournent mal, cela peut être embarrassant pour l'entreprise et frustrant pour les clients. Une série d'exemples sont fournis, y compris des incidents de Firestone Auto Care, Crunchyroll et Engadget, où les tests en production ont été mal effectués. Dans chacun de ces cas, les tests étaient visibles par les clients, ce qui n'est pas idéal. D'autres exemples incluent un article de test sur une boutique en ligne en direct, un message de test par défaut et un test de production qui a mal tourné par Amazon Prime Video. Ces incidents soulignent l'importance des tests en production, mais aussi la nécessité de les effectuer avec soin et discrétion. Les exemples fournis proviennent de diverses entreprises et industries, montrant que les tests en production sont une pratique courante. L'article se termine par une publicité pour ProGet, un outil qui offre des contrôles de sécurité et d'accès sur les flux NuGet. Dans l'ensemble, l'article met l'accent sur l'importance des tests en production, tout en présentant des exemples de cas où cela tourne mal.

Le code de Carol démontre une mauvaise approche de la sérialisation JSON en construisant manuellement des chaînes. Cette méthode est sujette aux erreurs et inutile, car C# offre des capacités de sérialisation JSON intégrées. Le code tente d'inférer les types de données pour la sérialisation en inspectant les représentations de chaînes. Il gère spécifiquement les tuples en convertissant les parenthèses en crochets. Il tente également d'analyser les valeurs en tant que nombres ou booléens pour déterminer leur représentation JSON. Toute autre valeur est traitée comme une chaîne et entourée de guillemets. Une faille critique est l'absence d'échappement correct des caractères dans les chaînes, ce qui peut conduire à un JSON mal formé si des guillemets apparaissent dans les données. Le code présente également un bug où une virgule supplémentaire est ajoutée à la chaîne JSON, qui est ensuite supprimée avec une vérification conditionnelle. Cette manipulation manuelle de chaînes est un signe de mauvaise pratique. Les développeurs doivent toujours utiliser les bibliothèques existantes ou les fonctionnalités du langage pour des tâches telles que la sérialisation JSON. Si une génération de code complexe est vraiment nécessaire, la construction d'un arbre syntaxique en premier est la bonne approche.

Henrik a rencontré un bug persistant où un service tiers fournissait des résultats incohérents. Les mises à jour envoyées par l'entreprise d'Henrik ne se reflétaient parfois pas correctement, et les lectures affichaient des données inexplicables. Le fournisseur a d'abord blâmé l'équipe d'Henrik, mais Henrik n'était pas convaincu. Il a collaboré avec des collègues et le fournisseur, développant des cas de test reproductibles sur plusieurs semaines. Ces tests suggéraient fortement que le service du fournisseur était en cause. Après une période de silence, le chef de produit du fournisseur a reconnu le problème. Ils ont identifié la cause première comme étant l'API qui identifiait occasionnellement mal la propriété des enregistrements. Leur solution proposée était de mettre en œuvre des identifiants uniques et non répétitifs pour les entités. Cette approche innovante était, en fait, le concept bien établi des clés primaires et des identificateurs uniques. Le fournisseur, malgré la connaissance commune de ces concepts, n'en avait apparemment pas conscience.

Mike a partagé une ligne de code Java qui, bien qu'elle ne soit pas un WTF en soi, suggère des problèmes sous-jacents. Le code déclare un tableau d'ArrayLists : ArrayList[] data = new ArrayList[dataList.size()]. Cela crée un tableau d'ArrayLists dont la taille correspond à dataList. L'auteur suppose qu'il pourrait s'agir d'une tentative d'utiliser l'orientation objet avec des listes. Il se pourrait que chaque objet de dataList soit converti en une ArrayList de ses valeurs. Le code pourrait précéder les génériques Java ou utiliser intentionnellement une version non générique pour cette conversion. Sans plus de contexte, cela reste une spéculation. Cependant, un tel code signale souvent un problème aux programmeurs expérimentés. Cette ligne sert de signal d'alarme quant à des complexités potentielles ou des défauts de conception. La présence de cette ligne suggère des problèmes plus profonds au sein de la base de code.

Bert travaillait à la fin des années 90 pour une entreprise de solutions logicielles qui servait principalement un client. Ce client avait demandé de l'aide pour corriger une application de planification de centre d'assistance lente qu'ils avaient construite. Initialement, Bert a découvert que la planification de seulement cinq employés prenait une heure et demie en raison d'un code VBA inefficace. Un exemple de cette mauvaise pratique de codage était une longue série d'instructions IF imbriquées pour convertir les mois indexés sur zéro en mois indexés sur un. Bert pensait que le logiciel était fondamentalement défectueux et qu'il n'était pas la bonne personne pour le réparer. Son patron, cependant, a insisté pour satisfaire le client pour des raisons financières. En quelques semaines, Bert a réussi à réduire le temps de planification à trente minutes. Cette amélioration a été jugée suffisante par son patron pour signaler le succès au client. Malgré cela, le programme n'a finalement jamais été utilisé et a été abandonné. Plus tard, Bert a appris que le client avait prévu de cesser les services de logiciels personnalisés et d'attribuer la tâche à un nouvel employé du département comptabilité, sans expérience en programmation. Cela suggère que la propre solution interne du client aurait pu être développée par quelqu'un sans expérience en codage.

La Bête Noire a connu un niveau de propane peu clair, le comparant à la superposition quantique. Darren a remis en question le tri des vues sur YouTube, suggérant une divergence dans l'interprétation des nombres. Christian L. s'est montré enthousiaste quant aux nouvelles de GitLab. Un individu anonyme a noté que l'heure d'été affecte négativement la météo, provoquant des baisses de température et du vent. B.J.H. s'est interrogé sur la syntaxe de commentaire appropriée, suggérant diverses options. Ironiquement, la tentative précédente de B.J. a échoué avec une erreur de serveur, ce que l'auteur maintient être toujours un problème de serveur. B.J. pensait que sa ligne d'objet commentée avait causé une erreur d'analyse. Le texte se termine par une publicité pour ProGet, promouvant des privilèges de flux NuGet restreints pour empêcher l'accès non autorisé aux environnements de production. Cela implique un besoin de contrôle d'accès robuste dans le développement logiciel.

L'article discute d'un entretien technique mal exécuté où un candidat a soumis un code problématique. L'interviewer, agissant en tant que soumissionnaire, a trouvé le code confus et probablement lié à un jeu similaire au tic-tac-toe. Le code contenait des erreurs de syntaxe et des défauts logiques, suggérant que le candidat essayait de vérifier trois symboles alignés verticalement. Le soumissionnaire spécule sur la fonctionnalité prévue mais note l'incomplétude et l'inexactitude de l'implémentation, ce qui a conduit à ce que le candidat ne reçoive pas d'offre. L'auteur passe ensuite à des conseils pour améliorer les entretiens techniques, tant pour les interviewers que pour les candidats. Ils soulignent que les entretiens doivent favoriser la conversation et permettre aux candidats de discuter de leur processus de pensée. Les interviewers sont encouragés à poser des questions et à s'engager activement avec les candidats, traitant l'entretien comme un effort collaboratif. Les candidats doivent être à l'aise pour faire des erreurs et écrire du code facile à refactoriser, car cela fait partie du processus d'apprentissage et de développement. Un conseil clé pour les interviewers est de changer leur état d'esprit, passant de "éliminer les imposteurs" à "recueillir des preuves pour défendre le candidat". L'objectif devrait être de trouver des raisons pour lesquelles un candidat *est* un bon candidat, en supposant qu'il ait atteint ce stade du processus. Les interviewers devraient rechercher ces preuves positives et donner aux candidats toutes les chances de faire leurs preuves. Si, après un entretien approfondi, des preuves positives insuffisantes sont trouvées, cela indique une inadéquation plutôt qu'un échec de la capacité intrinsèque du candidat. Enfin, l'auteur demande avec humour des soumissions de code particulièrement mauvaises pour de futures rubriques "Histoires d'entretien".

Kleyguerth a rencontré un bug déroutant où un indicateur `_hasPicked` s'est activé de manière inattendue. Ce problème provenait d'un commit récent et massif avec un commentaire vague. Le problème principal résidait dans la façon dont TypeScript gère les propriétés qui peuvent également être des fonctions avec des getters et des setters. Initialement, `checkAndPick` était un getter privé qui retournait simplement la valeur de `_hasPicked`. Plus tard, il a été modifié pour devenir `return this._hasPicked || (this._hasPicked = true);`. Cette version a muté `_hasPicked` en true s'il était false et retournait toujours true. Bien que cela ait été considéré comme une mauvaise pratique en raison de la mutation d'état dans un getter, cela fonctionnait comme prévu. La situation s'est aggravée lorsque le code a été modifié pour devenir `return this._hasPicked || !(this._hasPicked = true);`. Cette version a défini `_hasPicked` sur true mais a retourné false, causant des problèmes généralisés. Le défaut fondamental réside dans l'utilisation d'accesseurs de propriétés pour la mutation d'état, qui devraient être réservés aux setters. Une logique complexe, voire simple, ne devrait pas résider dans les accesseurs de propriétés.

Les calendriers sont des constructions arbitraires que les humains utilisent pour organiser le temps par commodité. Le calendrier de la Rome antique était géré par le Pontifex Maximus, un chef religieux qui pouvait également être un homme politique. Jules César a exploité ce double rôle à son avantage politique, manipulant les festivals pour perturber son opposition. Ses efforts ont abouti au calendrier julien, qui a servi de calendrier principal pendant environ 1500 ans. Le pape Grégoire a ensuite affiné le calendrier, corrigeant les calculs des années bissextiles et le réalignant avec les saisons, ce qui a nécessité de sauter treize jours. Le texte souligne que les dates ont historiquement manqué de logique intrinsèque. Il introduit ensuite un extrait de code Java problématique impliquant `GregorianCalendar` et `XMLGregorianCalendar`. Ce code tente de convertir un `GregorianCalendar` en `XMLGregorianCalendar`, puis de le reconvertir, en comparant les deux. Malgré la logique apparente suggérant une comparaison vraie, le processus de conversion en `XMLGregorianCalendar` est avec perte. Par conséquent, la fonction dans l'extrait de code renvoie toujours `false`. L'auteur s'interroge sur le but et l'utilité d'une telle vérification, soulignant la faillibilité humaine dans le codage. Le contexte historique sert à illustrer que les systèmes temporels ont toujours été sujets au changement et à l'inconvénient.

Un ticket urgent a signalé des espaces corrompus dans la saisie de données en production. Mike P a retracé le problème jusqu'à une fonction `trim` personnalisée dans `Strings.java`. Cette fonction maison était inefficace et boguée, remplaçant inutilement les séquences d'espaces par des espaces uniques. Notamment, elle retournait `null` pour les chaînes composées uniquement d'espaces, ce qui n'était pas le comportement utilisateur prévu. Le problème principal provenait des développeurs qui inventaient des exigences que les utilisateurs ne souhaitaient pas, entraînant une manipulation de données inattendue. La fonction `trim` personnalisée ne gérait pas non plus divers caractères d'espacement au-delà de Unicode 20. Les utilisateurs habitués au comportement antérieur de l'application ont paniqué lorsque les espaces ont commencé à disparaître. L'intention initiale était probablement de supprimer les espaces en début et fin de chaîne, et non de modifier l'espacement interne. Ce bug est passé inaperçu en raison de l'historique de l'application et du manque de tests pour de tels cas limites. La situation met en évidence les dangers de réinventer des fonctionnalités existantes avec des implémentations personnalisées défectueuses.

Un analyste qualité et audiophile a rencontré un problème sur napalmrecords.com où la mise à jour de son adresse de facturation nécessitait un numéro de maison important. Ce grand nombre, associé à un nom générique, a étonnamment passé la validation. Richard P. a découvert un échec de substitution dans la description d'un set Lego qui incluait un nom de produit basé sur un modèle. Mark T. a noté que les noms courts de frères et sœurs n'étaient pas autorisés pour une question de sécurité. Tim R. a signalé une faille de sécurité où Sainsbury/Argos exige trois informations pour le retrait d'un article. Il a souligné que l'envoi des trois informations dans le même e-mail va à l'encontre de l'objectif de la mesure de sécurité. L'auteur contraste avec humour son modèle de menace détendu pour les courses par rapport à la préoccupation de Tim. Le texte inclut ensuite une publicité pour un guide sur les meilleures pratiques NuGet pour les entreprises. Le thème général est le signalement de diverses erreurs de sites web et de systèmes.

De nombreux langages de programmation offrent des fonctions pratiques pour vérifier si une chaîne est nulle ou vide. C# dispose également d'une telle fonction, mais les développeurs peuvent toujours l'implémenter de manière incorrecte. La fonction `StringValid` de Jason, bien que fonctionnelle, est inefficace car elle utilise une instruction conditionnelle inutile. Une meilleure approche serait de retourner directement l'expression booléenne ou d'utiliser la fonctionnalité intégrée. L'approche de Derek utilise une seule ligne `"".Equals(Port)` qui est une manière inversée et moins intuitive de vérifier la nullité. Ce modèle a été trouvé dispersé dans la base de code, suggérant l'utilisation d'un extrait de code. La syntaxe inversée `"".Equals` pourrait avoir été influencée par des langages comme Python. L'exemple Java de Malfist implique une fonction nommée `checkNull` qui est trompeuse. Cette fonction est en fait une fonction de coalescence qui retourne une chaîne par défaut si l'entrée est nulle. Un défaut important est qu'elle coupe la chaîne d'entrée non nulle mais pas la chaîne par défaut. De plus, elle ne valide pas si la chaîne par défaut elle-même est nulle, ce qui peut entraîner d'autres exceptions de référence nulle. L'auteur exprime sa frustration face aux complexités de la gestion des chaînes, suggérant leur abolition.

Le code fourni illustre une fonction de formatage de date personnalisée du système de base de données 4th Dimension (4D). 4D, initialement nommé "Silver Surfer", était un SGBDR, un IDE et un langage de programmation développé dans les années 1980. Il a commencé sur le matériel Apple, manquant de peu de devenir un produit Apple avant que la pression des fournisseurs n'intervienne. 4D s'est étendu pour inclure des déploiements serveur/client, une compatibilité multiplateforme avec Windows et une prise en charge des applications web au fil du temps. Malgré ces avancées, 4D était souvent à la traîne par rapport à ses concurrents comme FileMaker et Access en termes de sorties de fonctionnalités. Le système a finalement intégré la prise en charge de SQL et de PHP, et l'entreprise continue d'exister avec des mises à jour peu fréquentes. Le problème principal n'était pas le code de gestion des dates lui-même, mais l'insuffisance des options de formatage de date intégrées dans la version de 4D de Brewster. En conséquence, Brewster a dû créer manuellement le format de date souhaité, révélant une limitation de la plateforme 4D. L'extrait met en évidence un exemple concret de la nécessité d'écrire du code personnalisé en raison des lacunes des outils.

La société de Chris a été confrontée à une augmentation inattendue des coûts de transfert de données lorsque son application web, hébergée sur le fournisseur de cloud B, a interagi avec une base de données MySQL sur le fournisseur de cloud A. Ils ne s'attendaient qu'à quelques gigaoctets de transfert de données par mois. Cependant, ils constataient des téraoctets, dépassant considérablement leur budget. L'enquête a révélé que chaque opération d'insertion récupérait une quantité énorme de données. La cause profonde était une requête SQL mal formée : SELECT last_insert_id() FROM some_table_name. Cette requête, au lieu de simplement récupérer le dernier ID inséré, était instruite pour renvoyer cet ID pour chaque ligne de la table spécifiée. Comme la table contenait des millions de lignes, cela a entraîné des millions de répétitions du dernier ID inséré renvoyées à chaque insertion. Par conséquent, chaque opération d'insertion générait un transfert de données substantiel d'environ 30 Mo. La mise en œuvre de la correction technique a été simple. Cependant, la coordination du changement avec la société de développement web et leur environnement d'hébergement, y compris les tests et le déploiement, a pris six semaines. Une partie de ce temps a été consacrée à convaincre les développeurs web que le problème se produisait effectivement et qu'il était causé par leur code.

Un développeur a rencontré un bug particulier où l'enregistrement de nouvelles entrées provoquait parfois des erreurs de clé primaire en double. Ce problème provenait du générateur d'ID de message personnalisé de l'application, qui utilisait l'horodatage actuel. Le générateur tentait de gérer les requêtes rapides en dormant pendant une seconde en cas de collision d'horodatages. Cependant, cette approche était inefficace et constituait essentiellement un compteur auto-incrémenté complexe. Une faille critique était que le `previousId` n'était jamais mis à jour, ce qui signifiait que les collisions n'étaient pas empêchées. Le problème était exacerbé car l'application était distribuée sur plusieurs serveurs. Cette distribution signifiait que même un `previousId` correctement mis à jour n'empêcherait pas les collisions d'ID entre différents nœuds. Les solutions potentielles impliquent l'incorporation d'identificateurs spécifiques à la machine, tels que les adresses MAC, ou l'utilisation de grands nombres aléatoires. Alternativement, le développeur suggère de s'appuyer sur la fonctionnalité d'auto-incrémentation native de la base de données au lieu d'un code personnalisé. Le débit actuel était suffisamment faible pour que la base de données puisse probablement gérer efficacement la génération d'ID.

The Beast in Black souligne les erreurs et les observations amusantes sur notre monde moderne. Weather.com présente un écart de température, mettant en évidence une erreur factuelle dans ses rapports. Une observation humoristique sur l'incohérence des données de température est présentée. Un utilisateur signale un dysfonctionnement du bouton de téléchargement dans un compartiment S3, mentionnant son absurdité similaire à celle d'un article référencé. M. TA se réjouit de ses gains financiers, partageant ses perspectives positives. David B. réfléchit avec humour aux retards de livraison de colis de l'USPS. Le passage reconnaît l'incertitude entourant le calendrier de livraison. L'auteur plaisante sur la nature imprévisible de l'USPS. Le texte se termine par une brève publicité pour une solution logicielle.

Le texte critique un morceau de code écrit par "Tobbi" qui combine JavaScript et PHP de manière médiocre. Le code utilise PHP pour générer des chaînes JavaScript, une pratique considérée comme un anti-pattern. Cet extrait de code spécifique effectue des appels AJAX, avec PHP qui affiche du code JavaScript définissant les requêtes AJAX. L'auteur souligne que le JavaScript affiché aurait pu être écrit directement, évitant ainsi le besoin de PHP. Le manque probable de prévoyance de Tobbi dans l'écriture de ce code est moqué par l'auteur. Le code, bien qu'inoffensif, est décrit comme un "brain-fart" (une idée stupide) indicatif de mauvaises pratiques de codage. L'auteur suggère que l'erreur s'est produite en raison de l'absence de revues de code ou d'une exécution faible. L'auteur conclut que des défaillances organisationnelles permettent l'intégration de code aussi défectueux. Le texte se termine par une publicité pour un produit lié au développement logiciel.

Brody a hérité d'une grande base de code gouvernementale non commentée avec des fonctions incroyablement longues. Au milieu d'une fonction d'environ 500 lignes, Brody a trouvé une seule accolade fermante commentée : `// }`. Cela suggère que le développeur d'origine a eu du mal avec la correspondance des accolades lors de la compilation. Le développeur a probablement commenté les accolades jusqu'à ce que le code compile, puis est passé à autre chose sans supprimer le commentaire. Cette pratique met en évidence un raccourci de codage courant pour corriger rapidement les erreurs. Le commentaire révèle une approche précipitée du débogage, privilégiant une solution rapide à la clarté du code. L'accolade commentée suggère que le développeur d'origine avait du mal à équilibrer les accolades dans son code. Le commentaire solitaire sert de témoignage silencieux des difficultés rencontrées lors de la création du code. Il souligne un manque d'attention aux détails et à la structure appropriée du code. L'histoire sert d'avertissement sur l'importance d'un code propre et bien commenté. La dernière ligne, ainsi que la publicité, ne sont pas pertinentes pour le récit principal.

Clément a rencontré un bug qui cassait l'interface utilisateur dans un système qui fonctionnait correctement depuis des années. Le problème n'était pas déclenché par un déploiement, ce qui suggère un problème lié aux données. L'application gérait des widgets affectés à des zones, qui déterminaient les zones d'un produit final. Le code défectueux utilisait une fonction `reduce` avec `_.union` pour calculer les zones du produit. Cette utilisation incorrecte de `_.union` avait pour conséquence que l'accumulateur ne conservait que la dernière zone. Cette logique défectueuse a étonnamment fonctionné pendant longtemps parce que les produits n'étaient pas répartis sur plusieurs zones. Au fur et à mesure que l'entreprise s'est développée, les produits ont commencé à s'étendre sur plusieurs zones, ce qui a mis en évidence le bug. Le calcul incorrect des zones a soudainement donné des résultats erronés, cassant l'interface utilisateur. La correction simple consistait à utiliser correctement la fonction `_.union` sur les tableaux de zones. Cela souligne l'importance d'une utilisation correcte des fonctions et l'impact des modifications de données sur le code existant. La publicité promeut une solution pour les flux NuGet sécurisés.

Les dates sont des types de données complexes, contrairement aux entités mathématiques plus simples comme les entiers, et présentent souvent des défis inattendus. Malgré cette complexité, les principes de la programmation fonctionnelle peuvent être appliqués efficacement à la gestion des dates. Cependant, certains développeurs ont du mal avec cela, comme l'illustre un exemple de code Java problématique. Cet exemple utilise une liste de trois fonctions lambda pour comparer deux objets `LocalDateTime` par année, mois et jour. Il diffuse ces fonctions, les applique aux dates et renvoie la première différence non nulle trouvée, avec une valeur par défaut de zéro si toutes les différences sont nulles. L'auteur exprime une forte désapprobation de cette approche, la jugeant inutilement alambiquée et fondamentalement erronée, bien qu'elle produise le résultat correct. L'auteur du code a remplacé toute cette logique complexe par une seule ligne de code élégante. Cette solution supérieure utilise la méthode intégrée `compareTo` après avoir converti les objets `LocalDateTime` en objets `LocalDate`. Cela démontre une manière plus idiomatique et efficace de gérer les comparaisons de dates en Java.

Brian a rencontré des résultats incompréhensibles des calculs de SkillCertPro, malgré sa note élevée. Maia a expérimenté un paradoxe temporel avec son client de messagerie, lisant des messages futurs. Jason a appris à utiliser Mailspring pour des commandes de musique ponctuelles, impliquant apparemment une machine à remonter le temps. Peter G. a rapporté avec humour des problèmes d'e-mail et de numéro de téléphone, soulignant l'amélioration des messages d'erreur. Adam R. a trouvé un bug de zoom du navigateur, bloqué à un niveau de zoom de NaN%. Le texte présente des anecdotes humoristiques de bugs technologiques et de comportements inattendus. Les problèmes vont des anomalies mathématiques aux dysfonctionnements des clients de messagerie et aux bizarreries des navigateurs. Le ton général est léger et anecdotique, axé sur les expériences des utilisateurs avec la technologie. Une publicité pour BuildMaster interrompt les histoires d'expérience utilisateur. Le court texte présente une collection de difficultés techniques amusantes.

Le code Java fourni commence par une méthode `getExtractedDataMap` qui appelle une méthode `setExtractedDataToMap`. C'est déroutant car les conventions Java dictent que les getters récupèrent des valeurs et les setters les modifient, ce qui rend un getter qui appelle un setter peu conventionnel. La méthode `setExtractedDataToMap` convertit un objet `PayloadDto` en une `Map`. La méthode `getExtractedDataMap` agit alors simplement comme un intermédiaire inutile. Le problème principal est qu'il s'agit de deux méthodes mal nommées où une seule méthode bien nommée suffirait. Un problème plus important est la conversion d'un objet Java en une `Map`, ce qui est une odeur de code indiquant un inconfort avec les principes orientés objet. Cette conversion n'est pas justifiée à des fins de sérialisation, car Java dispose de sérialiseurs intégrés qui gèrent cela de manière transparente. Les DTO eux-mêmes sont conçus pour une sérialisation facile des données. L'auteur exprime une confusion quant à l'objectif de ce code, faisant écho au sentiment du développeur qui l'a découvert. Le développeur d'origine a également renoncé à essayer de comprendre le flux de travail pour lequel ce code était destiné.

Un programmeur a partagé un extrait de code d'un projet de migration de .NET Framework vers .NET Core. Le code présente un `CustomerController` avec une méthode d'action qui traite un objet `Customer`. À l'intérieur de la méthode, une condition vérifie `customer.someProperty` pour décider quelle méthode `UpsertSomething` surchargée appeler. La méthode `UpsertSomething` est appelée avec une très longue liste de paramètres, dont beaucoup sont nuls ou des valeurs booléennes par défaut. L'auteur souligne que les deux appels à `UpsertSomething` sont presque identiques, ne différant que par un seul paramètre booléen. Cela suggère que l'instruction `if/else` était inutile. Au lieu de cela, la valeur de `customer.someProperty` aurait pu être passée directement comme argument à un seul appel `UpsertSomething`. L'auteur souligne cela comme un excellent exemple de pratiques de codage moins qu'idéales. L'extrait fourni est représentatif de la base de code plus large rencontrée lors de la migration. Le post sert d'exemple de la façon dont la complexité du code peut parfois être évitée avec des choix de conception plus simples.

Chops, un développeur chez Initrode, a été réprimandé par son responsable Gary pour un récent commit dans l'application Taskmaster. Gary était contrarié car le commit de Chops avait réduit le nombre de tests unitaires. Taskmaster, une application critique utilisée depuis des décennies, avait récemment subi un crash, que Chops a investigué. L'enquête a révélé une logique défectueuse dans la façon dont Taskmaster attribuait des identifiants uniques, ce qui entraînait des crashs potentiels et des boucles infinies. Chops a remplacé le code problématique par une implémentation UUID, supprimant les anciens tests unitaires problématiques. Gary, privilégiant une métrique spécifique (le nombre de tests unitaires), a exigé que la modification soit annulée. Chops a été contraint de restaurer le code défectueux et de mettre en œuvre une solution temporaire. Par conséquent, la stabilité de Taskmaster a diminué, gaspillant du temps et des ressources. En fin de compte, cette décision a augmenté le risque pour les utilisateurs internes et externes. Gary a privilégié la métrique à la santé de l'application.

Les machines à états sont des outils précieux pour structurer le code et simplifier des problèmes complexes. Cependant, une machine à états bien intentionnée peut rapidement devenir difficile à comprendre si elle est mal implémentée. L'extrait de code fourni présente une machine à états avec de nombreuses transitions définies. L'auteur peine à déchiffrer la fonctionnalité du code en raison de noms de variables peu clairs et de l'absence de commentaires descriptifs. Les fonctions `tk` et `sp` restent ambiguës, entravant la compréhension de leur rôle au sein de la machine à états. L'auteur identifie le troisième paramètre de `tk` comme des constantes représentant des actions, améliorant légèrement la lisibilité. Malheureusement, l'utilisation incohérente de constantes capitalisées rend le code plus confus. Dans l'ensemble, l'auteur critique le manque de lisibilité du code, rendant la machine à états difficile à comprendre. La frustration de l'auteur souligne l'importance de conventions de nommage claires et de commentaires complets. La publicité promeut une plateforme de gestion des versions pour gérer les versions d'applications.

Cette entrée traite des erreurs techniques humoristiques et des défauts de conception, en commençant par un clin d'œil au RGPD et à l'anglais européen. Un contributeur note un "schéma logiciel en vogue" impliquant des événements de pickleball. Un autre souligne les problèmes de la technologie juridique, notamment une version de logiciel confuse et des serveurs web mal configurés. Un écrivain australien plaisante sur l'utilisation inhabituelle des panneaux solaires en raison des saisons inversées. Quelqu'un d'autre partage une mise à jour humoristique de livraison DHL impliquant un "DHeLorean". Le concept de matériel "Error'd" est exploré, se demandant si une conception intentionnellement mauvaise est qualifiée. Un exemple spécifique concerne un composant de la loi sur les cookies avec des couleurs de bascule mal différenciées, soulevant des questions sur l'accessibilité et l'intention. L'auteur conclut en laissant le jugement de cette instance particulière aux lecteurs, se demandant s'il s'agit d'une véritable erreur ou simplement d'un choix de conception discutable.

Les variables booléennes peuvent contenir vrai ou faux, mais leurs noms manquent souvent de clarté. L'exemple `boolean isTrue = false;` met en évidence ce problème, où "il" reste non défini. C# propose à la fois les types `string` et `String`, qui sont identiques, ce qui peut conduire à un code potentiellement déroutant. Un extrait de code Java montre la gestion des valeurs nulles en retournant null si la valeur d'entrée `val` est nulle. Cependant, le commentaire dans ce code Java est redondant, car retourner `val` lorsqu'il est nul atteint déjà l'objectif déclaré. Un commentaire particulièrement peu utile dans une base de code indique "// Essentiellement, ..." suivi de milliers de lignes de code non commenté. Ce commentaire pourrait être interprété comme une reddition ou une blague ironique étant donné l'absence d'explication. L'extrait CSS fourni `.comment { border: none; }` concerne probablement la stylisation des commentaires sur une page web. Une publicité propose un guide gratuit pour aider à planifier les migrations vers .NET 9 avec confiance. Ce guide vise à prévenir les "migraines de migration" pour les développeurs. Le texte dans son ensemble partage des observations humoristiques et perspicaces sur le code et les commentaires de programmation.

David a rencontré une demande de tirage (pull request) déroutante avec des commentaires étendus axés sur un changement apparemment simple : l'ajout d'un seul paramètre à une fonction JavaScript. La fonction d'origine avait déjà sept paramètres, ce qui suggérait potentiellement une opportunité de refactoring pour utiliser un objet. La révision initiale a introduit une instruction conditionnelle liée à un nouveau paramètre, `notArg8`. Si `notArg8` était vrai, le code passait `arg8: !notArg8` au contexte. L'auteur ne pouvait pas comprendre cette approche compliquée, car il aurait suffi d'ajouter simplement le paramètre. David a commenté le mauvais code, mais le développeur d'origine a cessé de répondre. Un développeur junior a approuvé le changement de code confus, mais il n'a jamais été fusionné. Un autre développeur a ensuite simplifié la solution, en ajoutant simplement `arg8` et en le passant au `contexte`. Le code simplifié a fonctionné, a passé les tests et a rendu tout le monde heureux. L'intention du développeur d'origine et la raison derrière l'instruction conditionnelle compliquée restent un mystère. La fin suggère que la vision du développeur d'origine reste irréalisée.

Ellis, submergée par sa recherche d'emploi infructueuse qui durait depuis des mois, a assisté à un séminaire gratuit sur la recherche d'emploi en ligne. Le séminaire a fourni de bonnes informations, mais l'a laissée avec un sentiment de désespoir en raison des dures réalités du marché du travail, notamment les arnaques et l'automatisation. En s'appuyant sur ses mécanismes d'adaptation pour l'anxiété, Ellis a décidé de prendre une marche pour traiter ses émotions négatives. Elle a reconnu que négliger ces sentiments pourrait conduire à la paralysie et au désespoir. À son retour, elle a écrit ses pensées négatives sur la recherche d'emploi. En utilisant une technique de restructuration, Ellis a analysé et remis en question chaque déclaration négative. Elle a restructuré sa difficile recherche d'emploi en un processus d'apprentissage, la comparant à un algorithme de recherche naviguant dans un labyrinthe. Ellis a également trouvé un sens dans sa lutte, la considérant comme un acte de résistance contre le marché difficile. Elle a commencé à voir le potentiel de partager ses expériences et d'aider les autres. Cette période de chômage a également présenté une opportunité pour Ellis d'explorer de nouvelles possibilités, telles que l'expansion de sa carrière d'écriture freelance.

La fête du Travail, journée célébrant les travailleurs, met en lumière un conflit en milieu professionnel. Jordan, développeur, supervisait différents aspects d'un produit e-commerce. Les services commerciaux et le développement avaient des objectifs et des méthodes conflictuels au sein de l'entreprise. De manière surprenante, le contenu du site web relevait de la responsabilité du vice-président des ventes. Un problème est survenu lorsque le personnel d'entrepôt a confronté Jordan à propos du site web. Leur problème était lié à la page "À propos de nous". Le vice-président des ventes y avait qualifié le personnel d'entrepôt de "robots à viande". Le personnel d'entrepôt s'est senti méprisé par cette description. Le commentaire regrettable du vice-président a été attribué à l'alcool. Bien que l'entreprise ait finalement rattrapé son retard sur les commandes, cela a nécessité le remplacement d'employés d'entrepôt. Le vice-président des ventes, cependant, est resté employé et a même vu son titre s'élever.

Gordon S. suggère avec humour que l'IA introduit des erreurs pour créer l'illusion de résoudre des problèmes. Michael R. a partagé un lien vers daybreaker.com/alive/, indiquant une potentialité de républication. Michael R. a également commenté un suivi de colis erroné, exprimant de la sympathie pour le chauffeur DHL et remettant en question la direction du van. Morgan a rencontré des messages d'erreur inutiles sur une application de machine à laver, malgré le fonctionnement correct de l'appareil. Morgan a remis en question la logique de l'application, mettant en évidence des prompts d'erreur contradictoires. Stuart a spéculé que un filtre aurait pu mal catégoriser quelque chose comme une arnaque en raison de la présence du mot "arnaque". Il a remis en question l'hypothèse que toutes les arnaques contiennent le mot "arnaque". Le texte inclut également une publicité pour ProGet, un outil de gestion de paquets et de conteneurs Docker. ProGet offre une analyse de vulnérabilité et un contrôle d'accès. Une version gratuite est disponible, avec des options de mise à niveau pour plus de fonctionnalités.

Les types optionnels ont été introduits pour atténuer les exceptions de référence nulle, souvent appelées la « erreur de un milliard de dollars ». Ils fonctionnent en enveloppant une valeur, garantissant que l'Optional lui-même existe toujours. Cela permet aux développeurs de vérifier en sécurité la présence d'une valeur réelle. Les implémentations d'Optional bien conçues offrent des méthodes utiles pour la manipulation des valeurs. Cependant, ce concept peut être mal utilisé, comme le démontre la création de constantes statiques Optional pour VRAI et FAUX. Cette pratique est discutable, en particulier dans les langages qui fournissent déjà ces constantes booléennes. Créer des constantes comme Optional.of(Boolean.TRUE) équivaut essentiellement à VRAI = VRAI. De telles implémentations suggèrent des défauts de conception sous-jacents. L'auteur a rencontré cela dans une application web Spring, où des filtres personnalisés étaient implémentés au lieu d'utiliser les capacités du framework. L'exemple des déclarations de VRAI et FAUX statiques Optional met en évidence un problème plus large de réinvention de solutions existantes. Il implique une erreur de compréhension du problème original et de l'outil conçu pour le résoudre. Cette complexité inutile peut entraîner du code confus et inefficace.

Matt a hérité d'un codebase mal écrit en VB .Net issu d'une mesure d'économie de coûts précédente. Le code présentait un modèle problématique de génération d'HTML et de stockage dans une variable de session. Cet HTML devait être affiché sur une page d'impression séparée via une redirection côté client. La fonction responsable de la génération d'HTML, GenerateHTMLOfItem, ne prenait pas de paramètres, car l'ID de l'élément était déjà stocké dans une variable de session. Le mécanisme de redirection lui-même était inefficace, ce qui obligeait le navigateur à faire une nouvelle requête pour la page d'impression. La documentation Microsoft conseille contre l'utilisation de la surcharge de Response.Redirect, car elle termine le thread et affecte négativement les performances. L'alternative recommandée consiste à passer false au paramètre endResponse et à appeler CompleteRequest. Face à de nombreux problèmes, Matt a priorisé d'autres tâches, laissant ce code snippet particulier avec un commentaire désespéré. Malgré les inefficacités, cette pratique semblait avoir été adoptée par les développeurs, compliquant ainsi le codebase.

Le texte examine une fonction problématique d'un outil de recherche en C++ datant de trois décennies. Cet outil, principalement développé par des doctorants en informatique, présente de mauvaises pratiques de programmation. L'exemple spécifique mis en avant est une fonction nommée `isFooOrBar` qui effectue en réalité une opération ET entre `isFoo()` et `isBar()`. Ce décalage entre le nom de la fonction et son comportement est un problème important. De plus, l'auteur argue que même si le nom était correct, l'expression explicite `isFoo() && isBar()` est plus claire qu'une fonction dédiée. La fonction en question a été commitée comme nouveau code en 2010, suggérant un choix délibéré plutôt qu'une simple erreur. L'auteur original a probablement modifié la logique de OU à ET sans mettre à jour le nom. Cette décision a été prise pour éviter de mettre à jour tous les sites d'appel, malgré le fait que la fonction n'était utilisée que dans un seul emplacement. L'auteur suggère que l'intention réelle était d'encapsuler le comportement, ce qui n'a pas été atteint ici.

Un employé du support technique est appelé pour enquêter sur une imprimante défectueuse signalée par le PDG Lawrence Gibbs. À son arrivée, l'employé trouve une salle de conférence inhabituellement froide avec de nombreux employés présents. L'imprimante a produit de manière inexplicable des dizaines de pages blanches avec des cercles de café. L'employé soupçonne le PDG d'être impliqué, mais craint des représailles s'il le confronte directement. La nouvelle responsable des ressources humaines, Leila, offre discrètement son aide et sa confidentialité. Leila explique que Gibbs s'appuie sur l'imprimante, appuyant accidentellement sur le bouton de numérisation, ce qui imprime et envoie les scans par e-mail. L'employé élabore un plan pour retirer l'imprimante en prétendant qu'elle nécessite des réparations approfondies. Il réussit à faire enlever l'imprimante et à la placer dans un placard. En conséquence, la présentation d'accueil de l'entreprise présente maintenant un cercle de café comme leçon sur le respect des équipements. L'employé reconnaît le rôle de Leila dans la résolution du problème.

Mark R. propose un casse-tête de mots utilisant les lettres « housucops », suggérant un défi amusant. Le texte met en évidence des exemples de technologie ou d'expérience utilisateur problématiques. Gordon remplace une machine à stockage limité et est sceptique quant à la capacité de la nouvelle, peut-être en raison d'un modèle de langage large (LLM) impliqué. Un utilisateur anonyme critique l'expérience utilisateur de Greenmobility, la qualifiant de « cauchemar ». Jeffphi, un cinéphile, donne une critique négative d'une avant-première de film, la trouvant ennuyeuse. Manuel H. exprime le désir de week-ends prolongés plus fréquents, souhaitant un deuxième dimanche chaque semaine. Le texte comprend des exemples de frustration et d'insatisfaction des utilisateurs envers la technologie. Il y a une mention d'hallucinations d'IA, indiquant des erreurs ou des informations trompeuses potentielles. L'auteur commente une situation similaire à une soumission antérieure. La publicité promeut les fonctionnalités de sécurité de ProGet pour les flux NuGet. Le ton général oscille entre ludique, critique et aspirant, reflétant diverses expériences utilisateur.

"Aux débuts du web, les livres d'or et les compteurs de visites étaient des fonctionnalités courantes des sites web. Aujourd'hui, les entreprises continuent de suivre les données, en particulier les nombres de téléchargements. Justin a remarqué un compteur de téléchargements dans les analytics de son équipe et sur leur page de téléchargement, sans tout d'abord y trouver quoi que ce soit de remarquable. Il a également observé des commits fréquents pendant la nuit provenant d'un utilisateur nommé "MrStinky". Initialement préoccupé, Justin a finalement examiné les journaux Git et a vu un pattern d'updates incrémentales mineures du compteur de téléchargements. Ces mises à jour étaient générées par un bot qui interrogeait les analytics à chaque fois qu'un utilisateur cliquait sur le lien de téléchargement. MrStinky créait alors des commits, les regroupait, les approuvait, les fusionnait et redéployait les modifications pendant la nuit. Lorsque Justin a questionné ce processus, ses collègues ont expliqué que c'était la solution la plus simple et la plus rapide, ou que l'intégration directe de la base de données n'avait pas encore été mise en œuvre. Finalement, comme le reste de son équipe, Justin a priorisé d'autres problèmes sur cette méthode de comptage de téléchargements inhabituelle."

Jessica travaille sur une application Windows Forms héritée qui utilise une API obsolète. Elle a été chargée d'enquêter sur un rapport dont les performances sont médiocres. Le codebase est décrit comme du code spaghetti avec de nombreuses incohérences. Jessica a découvert une méthode appelée GetReportDiscounts qui exécute une requête SQL, mais qui, de manière paradoxale, effectue une sommation en C# qui est déjà présente dans la requête SQL. Cette méthode ignore également ses propres paramètres de date et utilise un nombre magique pour le filtrage. Une autre méthode, GetReportTotals, est presque identique mais utilise un autre nombre magique. Ces deux méthodes sont dérivées d'une méthode antérieure, GetCancelledInvoices, qui utilise correctement les paramètres de date. Cependant, GetCancelledInvoices effectue également le filtrage en C# au lieu de le faire dans la requête de base de données. Jessica a découvert que le rapport réellement problématique était une variante de ces méthodes, qui reposait sur le traitement côté client pour la manipulation des données. En refactorant ce rapport en une procédure stockée SQL avec un indexage approprié, les performances se sont améliorées de manière significative. L'article met en évidence le problème courant de copier-coller du code et d'effectuer des opérations de base de données de manière inefficace dans la couche d'application.

Les codes d'état HTTP ont des catégories théoriques pour faciliter leur utilisation : les 100 pour les informations, les 200 pour les succès, les 300 pour les redirections, les 400 pour les erreurs client et les 500 pour les erreurs serveur. Cependant, les implémentations du monde réel s'écartent souvent de ces normes. Par exemple, LinkedIn utilise un code 999 non standard pour l'accès non autorisé. Shopify a introduit ses propres codes personnalisés, et Apache a même un code 218. WebDAV complique encore les choses en ajoutant de nouveaux codes d'état et des verbes de requête HTTP. Un code généré tente de gérer les codes d'état HTTP en vérifiant si le code d'état divisé par 100 n'est pas égal à 2. Cette approche traite tout code d'état en dehors de la plage 200 comme une erreur. L'auteur critique cette méthode, en particulier la division par 100, arguant qu'elle signale incorrectement les réponses non-erreurs comme les 300 comme des échecs. Par exemple, un code 304 (Non modifié), qui indique que le contenu mis en cache est toujours valide, serait incorrectement identifié comme une erreur. Cette logique ingénieuse mais erronée a entraîné des requêtes échouées inutiles, démontrant une préférence pour les astuces mathématiques plutôt que pour une gestion d'erreurs robuste.

L'entreprise de Yusuf a connu une soudaine vague de messages de panique après un redémarrage routinier. Aucun changement de code ou de configuration n'a été déployé, laissant la cause inconnue. Le problème provenait d'une fonction responsable de la mise en place d'un client de base de données de documents. Cette fonction, `setupDocDBClient`, utilisait `docdb.NewClient` pour établir

Les erreurs techniques sont courantes, avec un utilisateur signalant une erreur de 900 unités et un autre mettant en évidence un « dialogue d'annulation » dans le gestionnaire de partitions KDE. Il y a des spéculations selon lesquelles une grande entreprise de médias pourrait négliger ses abonnés payants en raison du ralentissement des actualités en août. Un autre commentaire exprime des inquiétudes quant à l'idée que « zéro est une idée dangereuse ». Le texte se conclut par une déclaration sur « Échec ? Jusqu'à la prochaine fois » et une publicité pour BuildMaster.

Le code snippet fourni démontre une pratique de codage problématique où une ArrayList est utilisée pour passer plusieurs paramètres à une méthode. La méthode attend que l'ArrayList contienne des types de données et des valeurs spécifiques dans un ordre prédéterminé. Cette approche sacrifie la vérification de type à la compilation pour le risque d'erreurs à l'exécution. La justification de ce design était d'accommoder les changements potentiels futurs de la base de données sous-jacente sans modifier la signature de la méthode. Cependant, cela contourne les fonctionnalités standard du langage comme les arguments facultatifs, qui offriraient une solution plus sûre et plus maintenable. Le développeur a cru à tort que passer une ArrayList de cette manière rendait le code plus flexible. Ce modèle d'utilisation d'ArrayLists comme sacs de paramètres est prévalent dans tout le codebase. L'alternative des paramètres facultatifs aurait fourni une sécurité à la compilation et une intention plus claire. La mise en œuvre actuelle repose sur des hypothèses implicites concernant l'ordre et le type des données, ce qui conduit à un code fragile. Cette pratique est considérée comme un anti-modèle dans le développement logiciel.

"Les "vibe coders", ces développeurs qui s'appuient sur les LLM (grands modèles de langage), deviennent de plus en plus courants. Ces développeurs omettent souvent de lire, tester ou comprendre le code généré par l'IA. Ils ignorent également les normes de codage de l'entreprise. Un extrait d'exemple montre un schéma problématique d'utilisation des vérifications `isinstance`. Si l'enregistrement des erreurs pour les champs manquants est acceptable, la gestion des exceptions est hautement problématique. Le code déclenche une exception pour immédiatement la rattraper et ne rien en faire. Ce comportement spécifique est caractéristique des LLM générant du code statistiquement probable mais fonctionnellement inutile. L'exemple illustre comment les LLM peuvent interpréter les instructions littéralement sans appliquer de raisonnement logique. D'après l'expérience de Ronan, ce "vibe coder" particulier a été licencié. Son code généré par IA n'a jamais été intégré au projet. Cependant, le développeur a déjà commencé à rechercher un nouvel emploi avec des CV générés par IA. Cela souligne une préoccupation plus large concernant les compétences et les pratiques des développeurs s'appuyant sur les LLM."

JavaScript ne dispose pas de fonction intégrée pour arrondir à un nombre arbitraire de décimales. Les développeurs créent souvent leurs propres solutions, comme la fonction `stripExtraNumbers` fournie. Cette fonction convertit d'abord le nombre en chaîne de caractères pour vérifier la présence d'un point décimal. Si aucun décimal n'est présent, le nombre d'origine est renvoyé. Le code gère ensuite les entrées potentielles sous forme de chaînes de caractères en les analysant en nombres. Il utilise `toFixed(4)` pour arrondir le nombre à quatre décimales, renvoyant une chaîne. La fonction convertit ensuite cette chaîne en une autre chaîne pour supprimer les zéros de fin à l'aide d'une expression régulière. Enfin, elle analyse le résultat pour le reconvertir en nombre à virgule flottante. L'auteur critique cette approche comme étant inefficace et trop complexe, soulignant que les zéros de fin sont une préoccupation de formatage, et non une préoccupation numérique. L'exemple illustre comment des extraits de code mal compris peuvent conduire à des solutions alambiquées. Une approche plus simple et plus directe pourrait obtenir le même résultat avec moins de lignes de code.

Le code C++ fourni démontre une mise en œuvre défectueuse du patron de conception singleton utilisé pour les fonctions utilitaires. Une classe CUtilities est déclarée avec des méthodes utilitaires et un pointeur global, g_Utility. Le constructeur de CUtilities initialise g_Utility pour pointer vers l'instance actuelle. Cependant, ce setup ne prévient pas la création de plusieurs instances, ce qui entraîne des fuites de mémoire lorsque de nouvelles instances écrasent le pointeur. Une classe d'initialisation, CUtilityInit, a été utilisée pour créer une instance de CUtilities, appelant ainsi son constructeur. Le problème survient parce que le membre CUtilities à l'intérieur de CUtilityInit a été marqué comme inutilisé par un linter. Une employée, Olivia, a supprimé ce membre inutilisé. Cette action a cassé le programme car le pointeur global g_Utility n'a jamais été initialisé. La correction appropriée a consisté à initialiser directement g_Utility avec une instance au démarrage, plutôt que de compter sur l'approche singleton défectueuse. Le texte souligne que les singletons sont généralement une mauvaise pratique et que les mises en œuvre pauvres créent des problèmes significatifs. Les développeurs sont conseillés d'éviter d'utiliser des patrons de conception simplement pour le plaisir de les utiliser.

L'auteur est convaincu que la confession, même involontaire, peut guérir les âmes troublées, en particulier celles des développeurs web. Ils visent à exposer et à résoudre ces problèmes. Malheureusement, une soumission de Sam a été anonymisée, laissant les problèmes de xxxxxxxxxxte.com non résolus. Cependant, trois autres développeurs devraient bénéficier de ce processus. Reinier B. fait face à des problèmes de vérification d'e-mail pour visiter un zoo et vérifier sur des parents. Alex A. lutte pour payer les droits de douane. Sam B. note la difficulté de recruter de bons développeurs et suggère qu'ils ne font pas assez d'efforts. Peter G. trouve un appareil d'alimentation réseau d'Aliexpress problématique en raison de son nom de marque. Jan B. est mis en avant pour une soumission qui combine avec brio des "flubstitutions" avec des erreurs de référence nulle. Jan B. est confronté à un choix difficile entre deux options nulles pour un message de détection de localisation.

Le texte fourni traite d’une procédure stockée problématique dans MariaDB, documentée par un développeur nommé Salagir. Cette procédure, conçue pour récupérer les traductions, est présentée comme une mise en garde en raison de nombreux problèmes. Le code est marqué comme « code mort » mais est conservé pour sa valeur historique et les leçons qu’il offre. Le commentaire de Salagir met en évidence plusieurs difficultés rencontrées, à commencer par les incompatibilités syntaxiques entre les environnements de base de données. Un obstacle important concernait un paramètre de serveur global requis pour l’exécution de la procédure, qui a été facilement négligé. Le commentaire détaille également comment une utilisation incorrecte de l’index en raison d’incompatibilités de type de données a conduit à des analyses de table complètes. Le débogage de cette procédure était extrêmement difficile, obligeant les développeurs à recourir à la surveillance des listes de processus de base de données. Le problème le plus grave était la procédure provoquant des verrous de base de données invincibles, nécessitant une recréation complète de la base de données. Finalement, la procédure a été remplacée par une sous-requête plus simple, résolvant tous les problèmes rencontrés. L’auteur suggère qu’une telle fonction était une complication inutile pour une tâche facilement gérée par des opérations de base de données standard.

Les outils d'Object-Relational Mapping (ORM) offrent des avantages tels que la sécurité de type en mappant les relations de base de données aux types de langages de programmation. Cependant, un exemple spécifique met en évidence de mauvaises pratiques de codage. Le code itère à travers un `DataSet` ADO.NET déconnecté, qui modélise les données de la base de données en mémoire. L'accès aux tables par index (par exemple, `Table(0)`) au lieu du nom est inefficace. Plus important encore, la chaîne de récupération de données est inutilement verbeuse et sujette aux erreurs. Le code appelle répétitivement des méthodes comme `ToUpper` et `ToString` sur les champs de données. Cette chaîne devient absurde avec des appels `ToUpper` redondants pour "Tachometer". Un gestionnaire d'exceptions est utilisé pour les valeurs nulles potentielles, et non pour les erreurs de connexion à la base de données. Ce gestionnaire manque de vérification d'exceptions spécifique, supposant que seuls les nulls causent des problèmes. Un changement de schéma de table a cassé le code en modifiant l'indexation des colonnes, mais le gestionnaire a masqué l'erreur. Les utilisateurs ont rencontré des fonctionnalités défaillantes, comme des entrées "Pump Bracket" manquantes, sans messages d'erreur clairs. La boîte de message commentée suggère que des erreurs nulles fréquentes submergeaient les utilisateurs.