Je suis tombé là-dessus il y a peu, je m’en vais traduire, trahir, compléter, mettre à ma sauce le meilleur de ce verbiage humoristique de développeur humoristique plein de sagesse, que pour être franc je n’ai pas vu beaucoup en francophonie :

  • Condition Yoda : condition de la forme if (4 == mavariable) au lieu de l’instinctif if (mavariable == 4). Utile par exemple en C pour parer à certaines failles de sécurité, ou pour ma part (les quelques heures par décennie où je fais du C) à parer au fait que ce ☁#!☠☢☭⚡[1] de langage utilise le tout simple symbole = pour l’affectation et surtout l’autorise en plein milieu d’une condition.
  • Gestion d’exception à la Pokémon : elle est du genre :

try
{
// fait quelque chose
}
catch
{
// attrape les tous
}

alors qu’un principe de la gestion des erreurs est de ne pas chercher à gérer une exception dont on ne sait pas quoi faire. Si c’est pour loguer et sortir proprement du programme je comprends encore. Le pire consiste à tout mettre sous le tapis, comme l’ont fait certains Indiens vendus par un très grand éditeur là où j’ai presté il y a plus d’un lustre (c’est du PL/SQL) :

BEGIN
-- fait quelque chose impliquant des INSERT et UPDATE dans les tables
EXCEPTION
WHEN OTHERS THEN
NULL ; -- ignore tout problème et méprise le concept de transaction
END ;

  • Ne faites jamais confiance à un développeur en costard-cravate : disons qu’il a le droit de porter cravate le premier jour, le temps de savoir où il tombe, surtout s’il est dans le service, ou sur ordre. Certains diront qu’un vrai développeur n’ira jamais travailler dans une banque, mais il n’y a pas de place chez Google pour tout le monde, et certains préfèrent avoir un salaire pour payer leur famille que de ne vivre qu’en start-ups.

  • Les rapports de bugs issus d’utilisateurs non informaticiens constituent une des plaies du métier. Tout le monde n’a pas compris (même quand on lui explique) que dire « ça ne marche pas » ne constitue en aucune manière une information susceptible de mener à la résolution d’un problème. C’est aussi valable pour une voiture : ce qui ne se constate pas de manière flagrante en quinze secondes d’essai n’est pas un problème facile à trouver. Et encore, tout le monde sait utiliser une voiture de la même manière. Un informaticien non spécialiste d’un domaine ne verra pas que ce taux d’exécution budgétaire de 32% en décembre est farfelu ; dites-lui que ce doit être plus de 90% et il sera déjà mieux armé pour trouver le problème.
  • Smug report (« bug vantard » ?) : bug soumis par un utilisateur qui croit mieux connaître le système que son concepteur, avec des pistes sur la cause du problème, pistes d’autant plus fausses qu’elles sont affirmatives. J’ajouterai que certains utilisateurs sont champions pour faire un lien entre deux événements sans rapport, du genre d’un plantage d’imprimante qui aurait provoqué une erreur dans le logiciel de planification.
  • Drug report (« rapport de drogue ») : rapport de bug incompréhensible, apparemment rédigé sous acide.
  • Bug de Fermat : le rapport de bug contient un commentaire indiquant que la solution a été trouvée, en n’indiquant en rien quelle est sa nature. Très fréquent dans les forums internet.
  • Contre-bug : bug présent comme défense contre un bug que l’on vous présente. Utile dans les guéguerres entre équipes ou (pire) entre fournisseurs.
    « Votre logiciel de compta rame, on pourra pas faire la paye !
    - Ah désolé ma p’tite dame, c’est un bug connu de votre version de votre base Oracle, rappelez-nous quand vous aurez patché. »

  • Bug flottant : bug surnageant dans l’outil de suivi, jamais assigné, ou refilé de personne à personne. Il y a un contournement efficace, le correctif est flou, délicat, trop long, fastidieux, sans intérêt, ou touche à trop de domaines différents avec trop de risques d’explosion par la suite… Bref, ce bug a de bonnes chances d’être ignoré, puis explicitement filtré pour ne pas polluer les tableaux des responsables de projets, donc de rester des années dans le logiciel jusqu’à ce que tout le monde considère qu’il s’agit du fonctionnement normal.
  • Heisenbug (mon préféré) : bug qui change quand l’observe.
  • Schrödinbug : comme le chat de Schrödinger, le bug oscille entre l’existence et la non-existence (le résultat du programme est souvent correct) jusqu’à ce qu’un développeur inconscient soulève le capot et regarde. Le bug devient alors permanent.
  • Bug de Higgs : bug dont l’existence n’est suggérée que par quelques entrées dans les logs et de vagues mentions anecdotiques. Impossible à reproduire sur une machine de dév’ car en fait on ne sait pas trop ce qui se passe. Pour le débuguer il faudra investir dans des systèmes de surveillance très lourds.
  • Bug du Loch Ness : bug qui n’a été rapporté que par une seule personne.
  • Hindenbug : bug d’ampleur catastrophique, du genre qui fait crasher en flamme tout le projet.

  • Bug OVNI : bug reporté encore et encore par des clients à qui l’ont a pourtant montré qu’il n’existe pas.
  • Mandelbug : bug tellement complexe que son occurrence ne semble pas déterministe, c’est-à-dire chaotique.

  • Bug d’apprenti sorcier : bug (en général dans un protocole de communication, une boucle…) menant à la génération de nouveaux messages, objets buggés, qui eux-mêmes en génèrent d’autres… menant ainsi soit à l’invasion de l’univers par les bugs, ou plus probablement, les ressources informatiques ou autres étant finies, à l’effondrement du système du bug.
  • Bug Excalibur : le bug que tout le monde a essayé de corriger, en vain jusqu’ici.
  • Bug vital : les utilisateurs considèrent que le bug fait partie du fonctionnement normal du logiciel, voire basent une partie de leur fonctionnement dessus. Ils refuseront que cela change même si on leur montre qu’ils font n’importe quoi ou que le bug est une faille de sécurité béante.
  • Fonctionnalité : It’s not a bug, it’s feature, selon Microsoft, ou plutôt (selon Apple dès 1979) un « bug décrit par le marketing ».
  • Refucktoring : retravailler un code peu maintenable mais fonctionnel pour le massacrer complètement et y introduire plein de bugs. En général le code n’en sortira pas plus maintenable, mais bien plus boursouflé et moins fonctionnel.

À propos des différents types de code que l’on peut rencontrer (parce que le code informatique est à peine moins marqué que la littérature par les questions de style) :

  • Code spaghetti : tellement plein de GOTOs, d’exceptions, de threads… et autres branchements non structurés, que suivre le déroulement de ce code est aussi fastidieux que de démêler un spaghetti dans une assiette pleine.
  • Code spaghetti avec des boulettes de viande : comme précédemment, avec des morceaux de tentative de structuration.
  • Code baklava ou code lasagne : du code avec beaucoup (trop) de couches d’abstraction empilées. Je dirais que N développeurs produiront souvent N couches de code.
  • Code ravioli : code objet consistant en un petit nombre d’objets faiblement liés (en soi, une bonne chose).
  • Code andouillette : code qui pue et dont on ne veut pas connaître la composition.
  • Château de carte : touchez une chose, tout s’effondre.
  • Hydre : chaque correction de bug en engendre deux autres.
  • Code balafré : plein de cicatrices à cause de toutes les rustines qu’on y a appliqué.
  • Code mort : toujours là mais commenté, ou (pire) jamais appelé.
  • Assurance contre le licenciement  : code tellement obscur et bardé d’historique que la personne chargée de la maintenance a l’assurance de ne jamais être virée. Les effets pervers sont : l’impossibilité de changer de boulot et donc de monter dans la hiérarchie pour la même raison ; et le risque que la mise à la retraite du logiciel implique le licenciement immédiat du mainteneur qui ne servait plus qu’à ça et n’a pas suivi la montée en compétence de ses collègues.
  • Ghetto : partie du logiciel où personne ne va, avec ses lois obscures, et qui doit faire des choses pas catholiques, mais qui ne gêne pas le reste.
  • Code copier-coller : code de débutant qui n’a pas compris le concept de fonction ou de procédure, bref de réutilisation.
  • Palimpseste : comme les parchemins du Moyen Âge, un code avec beaucoup d’historique révèle en creux bien des pans de son histoire, par exemple des tailles maximales de certaines informations ou certaines structures de données liées à des contraintes sur des applications depuis longtemps oubliées.
  • Développement défensif : manière de programmer consistant à considérer que Murphy s’attaquera activement au logiciel, ce qui mène à ne considérer aucune entrée comme sûre, à tout retester, etc. Pas forcément un mal dans certains milieux où la paranoïa est reine : médical, aéronautique...
  • Protoduction : prototype que l’on teste directement en production. Pas forcément un mal, parfois le seul moyen de tester même, quand on en est conscient. Catastrophe annoncée si les managers ont imposé qu’une maquette soit promue en prod’ sans même que le développeur en soit informé (évidemment, la responsabilité de tout problème lui retombera dessus).

Note

[1] Vous saviez qu’il y avait tous ces symboles dans Unicode ? Je viens de découvrir (merci Wikipédia).