Projet symfony. Je code, tout se déroule bien, fin de semaine, je balance mon code sur le serveur de recette, et je jette un coup d’œil sur l’environnement de prod. Horreur ! Page blanche ! Je vérifie la même page sous l’environnement de dev. Elle s’affiche correctement.

Je jette un coup d’œil dans la log apache :

child pid 16813 exit signal Segmentation fault (11)

Un sentiment d’immense lassitude m’envahit aussitôt.

Après une longue et pénible session profilage / debugage avec xdebug, je finit par circonvenir plus ou moins l’endroit du problème, et parviens même à le reproduire à l’envie. Vous allez voir, c’est surprenant :

$category = Article->getCategory(); // objet de classe 'Category'
echo $category;  // Affiche le titre de la catégorie
printf('%s', $category); // Page blanche, segfault, sacrifice de chatons, etc.

Amusant, non ? Après quelques recherches, il semblerait que dans le contexte d’une fonction *printf, php n’utilise pas la fonction magique __toString().

Je teste donc :

<?php
 
class Toto
{
  private $tata;
 
  public function __construct($tata)
  {
    $this->tata = $tata;
  }
 
  public function __toString()
  {
    return (string) $this->tata . "\n";
  }
}
 
$toto = new Toto('tutu');
echo $toto;
printf('%s', $toto);
 
// tutu
// tutu

WTF ? Mais ça marche trés bien ! C’est donc un problème spécifique à mon code ? Je poursuis mon débuggage, et j’arrive ici :

$category = $article->getCategory();
// $category est de la classe sfOutputEscaperIteratorDecorator
// qui hérite de sfOutputEscaperObjectDecorator
// qui définit une fonction __toString()
 
printf('%s', $category);
// Appelle sfOutputEscaperObjectDecorator::__toString

Bon, allons voir sur place ce qui ne va pas.

class sfOutputEscaperObjectDecorator
{
…
  public function __toString()
  {
    // Jusqu'ici, tout va bien, mais dés l'instruction return, ça plante
    return $this->escape($this->escapingMethod, $this->value->__toString());
  }
 
  // Je modifie donc la fonction pour obtenir ceci :
  public function __toString()
  {
    $value = $this->escape($this->escapingMethod, $this->value->__toString());
    var_dump(gettype($value));
    var_dump($value);
    die();
    return $value;
  }
 
// J'obtiens pour affichage :
// 'String'
// 'Titre de ma catégorie'
 
// En revanche :
 
  public function __toString()
  {
    $value = $this->escape($this->escapingMethod, $this->value->__toString());
    var_dump(gettype($value));
    var_dump($value);
    // die();
    return $value;
  }
 
// Page blanche. Continuons dans l'étrange, avec quelques modifications de la même méthode :
 
  public function __toString()
  {
    $value = $this->escape($this->escapingMethod, $this->value->__toString());
    die('ici'); // Affiche 'ici'
    return 'toto';
  }
 
  public function __toString()
  {
    return 'toto'; // Affiche 'toto'
  }
 
  public function __toString()
  {
    $value = $this->escape($this->escapingMethod, $this->value->__toString());
    return 'toto'; // Page blanche
  }
}

Tout ça, bien sûr, c’est sur l’environnement de prod. En dev, tout se passe toujours normalement.

J’en suis là. Si quelqu’un a une bonne explication. En attendant, je crois que je vais aller me coucher de bonne heure. Bon week-end à tous.

photo credit : Pieter Musterd

Dés qu’elle est entrée dans mon bureau, j’ai su que l’affaire ne sentait pas bon. On ne fait pas carrière dans ma branche si on ne développe pas un solide sixième sens pour flairer les problèmes. Et manifestement, mon embrouillomètre me criait que je ferais mieux de me planquer sous mon bureau la tête cachée dans une des poches de mon imper.

Malheureusement, mon vieux fauteuil donnait des signes de fatigue, la machine à café agonisait, et j’avais un besoin urgent de renflouer mes caisses. Je n’avais pas les moyens de faire le difficile.

— Thibault Jouannic, détective TMA privé ?
— Lui même, à votre service m’dame. Entez, je vous en prie.

D’un signe de main, je l’invitai à s’asseoir. Pendant qu’elle s’exécutait, je l’examinais à la dérobée. Mon boulot m’amenait plutôt à côtoyer de gros barbus aux dents jaunies par la clope et le café, et portants des tee-shirt rigolos. Aussi, cette belle brune élancée en tailleur élégant avait immédiatement éveillé mon attention. D’un point de vue professionnel, j’entends.

— Alors m’dame, que puis-je faire pour vous être utile ?

J’ai toujours pensé qu’un bon détective était comme un médecin. Pas de bon diagnostic sans connaître les symptômes. Le problème, c’est que mes clients me prenaient souvent pour une espèce de devin vaudou, et j’étais obligé de les soumettre à un interrogatoire digne d’un inquisiteur espagnol pour espérer obtenir le minimum d’indices.

— Je suis Lucie S., webmaster d’un site de petites annonces agricoles, et depuis quelques temps il semble que les performances ne soient plus au rendez-vous.
— Vous voulez dire que le site est lent ?
— En fait, ce site n’a jamais été une foudre de guerre, mais depuis deux jours, la situation est devenue catastrophique. La moindre requete nécessite 45 secondes avant d’aboutir. Quand on ne récupère pas une page blanche. Et le moteur de recherche, le cœur du site, est complètement inutilisable.

photo credit : Balakov

Les performances ! Un grand classique. 90% de mes affaires concernaient des sites qui se trainaient comme des escargots neurasthéniques. Parfois, rajouter quelques caches rendait le problème supportable, mais la plupart du temps, la conception de base était tellement médiocre qu’il n’y avait rien à faire. Allez expliquer ça à un client désespéré.

Bref ! Cela s’annonçait comme une petite enquête de routine. Alors pourquoi mon instinct me criait-il qu’il y avait anguille sous roche ?

— Vous dites que depuis deux jours, la situation a empiré. Que s’est-il passé de spécial à ce moment là ?
— Mais justement ! Rien, rien du tout.

C’était louche. Soit elle me mentait, soit elle ignorait quelque chose, mais son histoire n’était pas crédible, et elle même ne semblait pas convaincue. Je décidai de la titiller.

— Aucune erreur dans vos tests unitaires ou fonctionnels ? Que dit votre plate-forme d’intégration continue ?
— Euh…

J’avais touché juste. Je posais la question pour la forme, j’aurais été bien surpris d’apprendre l’existence de tests automatisés. La plupart du temps, je devais m’estimer heureux si des conventions de codages étaient définies et respectées. Mais bon, la question avait le don de rendre mes clients mal à l’aise, et un client qui n’est pas droit dans ses chausettes est moins enclin à discuter mes tarifs. Et puis, ça me distrait.

— Écoutez, je vais voir ce que je peux faire. Mais il me faudra un accès au serveur de production, un compte sur le gestionnaire de source, et un dump récent de la base de données.
— Je vous communiquerai ces informations dans la journée. Il y a autre chose, me dit-elle l’air embarassée.
— Oui ?

Je masquai un petit sourire. Quand un client ne rechigne pas à vous donner l’accès à la prod, c’est qu’il y a toujours autre chose.

— Un grand salon d’agriculture a lieu dans deux jours. Une présentation publique du site est prévue. C’est un site subventionné par le ministère, vous comprenez. Et si la situation n’est pas revenue à la normale d’ici là, nous risquons de nous retrouver dans une situation délicate.

Ben voyons ! J’aimais travailler dans le stress du temps qui passe. Corriger un bug qui semblait insolvable est gratifiant, mais aucune sensation n’est plus exaltante que celle de le faire dans un délai aussi court. Et puis, ça me permet de gonfler mon tarif.

— Je prends l’affaire en main m’dame. Envoyez moi les données dont j’ai besoin, et je commence sur le champ.

photo credit : Anders Adermark

Une fois qu’elle fut sortie, je m’abandonnais à une méditation contemplative. Réfléchir représente une part importante de mon temps de travail. Je dirais même que c’est la part la plus importante. Il m’est même arrivé de résoudre des affaires sans poser les mains sur mon clavier bépo.

L’ennui, avec la réflexion, c’est qu’elle passe facilement pour de l’oisiveté pour les non-inités. C’est pour ça que je prends toujours l’air affairé et soucieux quand j’attends un client. Pour avoir l’air compétent et efficace.

C’est important, les apparences, dans mon métier. Pourquoi croyez-vous que je laisse traîner toutes ces piles de dossiers poussiéreux ? Pas pour le travail, tout est numérisé. Non, c’est simplement parce qu’un détective sans imper et qui ne pue pas le tabac froid. Ça ne fait pas sérieux.

Je suis bien resté deux heures, les pieds sur mon bureau couvert de paperasse bidon, sirotant mon infusion à la verveine (que je ne bois qu’en cachette, un vrai détective est censé carburer au café noir dégueulasse), avant de parvenir à la conclusion suivante : j’étais dans une impasse. J’avais le crime, mais pas le mobile.

Quelqu’un aurait-il saboté volontairement le site pour plomber la présentation publique ? Un hacker ? Un script-kiddie ? Un concurrent ? Je n’arrivais pas à m’en persuader. Les gens regardent trop la télé. Ils s’imaginent que nous autres, détectives TMA, passont notre temps à combattre le crime virtuel organisé, sauver des demoiselles en détresse et empêcher in-extremis des fusées d’exploser. Tout ça, c’est la faute à Colombo.

La réalité est toute autre, et le quotidien d’un détective TMA est finalement assez banal. Point de grand bantitisme. Point de course poursuite effrénée dans les limbes du web. Simplement quelques corrections orthographiques par ci, un petit bug css (damn IE!) par là. Et puis, métro, popote, dodo. Comme tout le monde, finalement.

C’est justement pour cette raison que je ne parvenais pas à accepter l’idée d’un acte de piraterie. Règle n°1 du détective TMA : «  N’attribue jamais à la malveillance ce qui peut s’expliquer par l’incompétence  ». Quelqu’un avait merdé dans cette histoire, et il fallait trouver qui.

photo credit : Pensiero

C’est maintenant que les choses sérieuses allaient commencer. Je commençai par vérifier la justesse des informations envoyées par ma cliente, et récupérais le trunk du site. Haha ! Quelqu’un avait commité un «  Thumbs.db  » dans le dossier «  img  ». Quelle bande de newbies ! Mais !? Ils avaient également commité leur répertoire de backup, rempli de dumps sql ?! Seigneur ! Je sentis mes yeux tenter de jaillir hors de leurs orbites.

Pris d’un doute, je récupérai également en local la version de production du site. Autant vous dire qu’à ce moment, je m’attendais à tout. Pour le plaisir, j’ouvris quelques fichiers au hasard grâce à mon éditeur de geek préféré (vim, car tout le monde sait que les vrais pros n’utilisent jamais emacs). La syntaxe hasardeuse, l’indentation erratique, et les caractères de saut de lignes aléatoires me firent vite tourner la tête, le cœur au bord des lèvres.

— «  Fiston, dans la vie, on ne mélange jamais les espaces et les tabulations  », me disait souvent ma grand-mère, de son air sage et pénétrant de vétéran qui avait connu le Cobol. Il faut croire que tout le monde n’a pas eu la chance d’avoir une grand mère comme la mienne.

En dernier recours, je décidai de jeter un coup d’œil à l’historique svn. En parcourant rapidement les derniers messages de commits, quelque chose attira mon regard. Serait-il possible que… Quelques diffs plus tard, j’étais fixé. Les mains derrière la tête, je me laissai aller en arrière, un sourire sur les lèvres. Voilà une affaire rondement menée.

Le cœur léger, je décrochai le téléphone, et appelai ma cliente.

— Allo ?
— Thibault Jouannic, détective TMA à l’appareil. J’ai quelque chose qui peut vous intéresser.
— Vous avez trouvé ?
— Pas par téléphone. Écoutez, je veux que vous réunissiez l’équipe de développement au complet, dans vos locaux, demain 9h. Assurez-vous que tout le monde soit présent. Et amenez des croissants.

photo credit : Elmo Alves

Sans attendre sa réponse, je raccrochai. Pour ma peine, je décidai de me préparer une autre infusion. Demain promettait d’être une belle journée.

Le lendemain, je me rendis au siège de S… S.A., dans ma vielle guibarde fumante. J’ai l’habitude de me déplacer en vélo, mais pour les rencontres avec mes clients, ça me donne un genre.

Quand j’arrivai à la réunion, tout le monde était déjà présent, et à l’heure, preuve s’il en est de la gravité de la situation. Les croissants étaient chauds, le café finissait de glouglouter dans le percolateur, les choses s’annonçaient bien.

Je m’emparai d’une viennoiserie, et demandai à chacun de se présenter.

— Frédéric B., chef de projet
— Solange C., développeuse
— Alfred D., designer / intégrateur
— Anatole P., développeur stagiaire
— Pierre Z, développeur
— Lucie S., webmaster

Après ce petit tour de table, je leur tournai le dos, et m’approchai de la fenêtre, faignant de contempler le paysage bétonneux des alentours d’un air inspiré. Dans mon métier, il faut savoir ménager ses effets. Lorsque je jugeai la tension nerveuse suffisante, je me retournai, et commençai mon numéro.

— Comme vous le savez, j’ai été contacté hier par Lucie S., ici présente, pour élucider un cas mystérieux. Depuis 2 jours, le site www.….com semble rencontrer des problèmes de lenteur anormale. Est-ce exact ?
— Tout à fait.
— Cet évenement survient juste avant une importante présentation publique du site. Si l’anomalie n’est pas résolue, sa réputation sera ruinée, et par exension celle de l’agence web qui l’a conçu et réalisé, n’est-ce-pas ?
— En effet.
— Comme vous, j’ai pensé à un acte malveillant. La vile démarche d’un concurrent amer et jaloux d’avoir été éconduit lors de l’appel d’offre. Aussi ai-je analysé en détails les différents logs de votre serveur de production. J’ai vite découvert que je faisais fausse route. Je n’ai rien remarqué d’anormal. En revanche, je peux vous dire une chose.

Je les parcourus tous de mon regard de détective pénétrant. La tension était à son comble, chacun était pendu à mes lèvres, retenant son souffle.

— Mesdames, messieurs, il s’agit d’un acte interne. Qui plus est, j’affirme que le coupable se trouve dans cette pièce !

L’annonce fit son effet. Des exclamations d’indignation éclatèrent, des cafés furent renversés, certains manquèrent s’étouffer avec leur croissant. J’attendis, inflexible, que le calme revienne, et imposai le silence de mon œil de lynx (la bestiole, pas le navigateur).

— Lucie S., vous m’avez annoncé lors de notre premier entretien qu’aucun changement n’étais survenu sur l’application au moment du début des anomalies. Et bien, madame S., vous vous êtes trompée. Il y a bel et bien eu une livraison ce jour là.

Le chef de projet bondit alors de sa chaise, en renversant son café, hurlant presque.

— Mensonge ! Calomnies ! Aucune livraison n’a été déployée en production depuis 10 jours. Vérifiez le svn, le dernier tag date de plus d’une semaine. Et aucun ticket n’est passé en état «  cloturé  » durant cette période ! Vous mentez !
— Croyez-moi bien, j’ai vérifié ces éléments. Et comme vous le dite, aucune livraison n’a été déployée en utilisant votre procédure de livraison officielle. — J’appuyais sur le terme — En revanche, il y a bien eu une livraison sans passer par votre procédure de déploiement !
— C’en est trop, rugit le chef de projet. Comment pouvez-vous l’affirmer ?
— C’est simple, j’ai eu l’occasion de comparer la version svn des sources, avec ce qu’on peut trouver sur vos serveurs de production et préproduction. Le résultat fut trés instructif, je dois dire.

photo credit : maistora

Je les observai d’un air amusé, avant de reprendre.

— J’ai en effet pu constater que ces trois environnements n’étaient pas synchronisés. Il ne peut y avoir qu’une seule explication. Quelqu’un n’a pas respecté votre procédure de déploiement.

L’assistance resta muette. Des murmures incrédules se firent entendre. Le chef de projet, hagard, bafouilla.

— Mais… Qui ? Qui pourrait faire une chose pareille ?
— Voyez-vous, j’ai eu l’occasion d’analyser les logs svn de votre application. Quelque chose a attiré mon attention. Quelque chose qui n’aurait pas du se trouver là.

Suspense. J’observai une pause théâtrale, avant de m’écrier :

— Votre log svn est en effet truffé de messages de commits vides !

Stupeur dans l’auditoire. Le chef de projet, le souffle coupé, retomba sur sa chaise, effondré. Je m’emparai d’un croissant, leur laissant le temps de reprendre leurs esprits avant de continuer.

— Plus intéressant. J’ai également remarqué que ces commits félons se sont multipliés depuis quelque temps.

Je pointai alors un doigt vengeur vers l’un de mes auditeurs.

— Monsieur Anatole P. Pourriez vous nous indiquer à quel moment vous avez commencé à travailler sur ce projet ?!

Le pauvre stagiaire, au comble de l’embarras, parvint à peine à bredouiller une réponse intelligible.

— Une… une semaine environ. Mon stage a débuté au début du mois.
— Monsieur Anatole P. N’est-il-pas vrai que vous avez, au cours de cette semaine, réalisé des développements sur le site dont nous parlons ?
— Oui, mais…
— Et n’est-il-pas vrai qu’au cours de ces travaux, vous avez modifié l’un des fichiers de configuration de l’application ?
— Peut-être bien que oui.
— Et bien monsieur Anatole P., lorsque vous avez livré vos travaux directement sur le serveur de production, vous avez écrasé un fichier de configuration avec les paramètres de la plate-forme d’intégration. Cela a eu pour action de désactiver tous les caches de la production !

photo credit : TarikB

Dans la folie qui s’ensuivit, le chef de projet, rouge de colère, tonna.

— Anatole ! Je vous jure que vous allez…
— Un instant ! — J’avais usé de toute mon autorité pour l’interrompre — J’affirme qu’il n’y a qu’un seul coupable dans cette pièce. Et ce coupable n’est pas Anatole.

Stupéfaction.

— Monsieur Frédéric B., chef de projet du site www.….com, je vous accuse d’avoir confié les accès de votre plate-forme de production à un stagiaire inexpérimenté. Je vous accuse de l’avoir laissé travailler sur un projet sans l’avoir formé à vos méthodes. Je vous accuse de ne pas avoir mis en place de procédure systématique de vérification ni de validation de son travail par ses pairs plus expérimentés. Enfin, au nom d’Ada, sainte patronne des geeks et codeurs, je vous accuse de contribuer à la médiocrité logicielle générale, en omettant de mettre en place et de promouvoir des bonnes pratiques de développements. Arrêtez-le !

Deux gorilles de la sécurité se saisirent du félon, et l’emmenérent tandis que ses cris de rage et menaces de vengeances raisonnaient dans les couloirs.

Quand le silence revint, je savourai les regards admiratifs qui se posaient sur moi. Ma cliente ne put s’empêcher de me demander :

— Mais comment avez-vous su ? Pour la livraison en production ?
— C’est simple, ma chère. Lorsque j’ai réalisé que certains fichiers n’étaient pas synchrones entre les différents environnements, j’ai fouillé pour en découvrir l’origine. J’ai remarqué que certaines modifications apportées récemments sur le svn se trouvaient bien sur la préproduction, mais jamais sur la production. En revanche, d’autres commits avaient été directement reportés sur la production, mais étaient absent de la production. Et il se trouve que ces commits anormaux avaient tous un même auteur : Monsieur Anatole P., ici présent.

En remontant dans l’historique, j’ai tout de suite vu que ses premières contributions étaient trés récentes. J’ai évidemment pensé à un stagiaire.
— Votre analyse est limpide.
— Élémentaire, même. Cette affaire prouve une fois de plus l’une des Grandes Lois Immuables des TIC.
— Laquelle ?
— Il n’existe pas d’anomalie, quelle qu’elle soit, dans laquelle aucun stagiaire ne soit impliqué.
— Écoutez, monsieur Jouannic. Vous nous avez démontré que vous êtes un homme capable. Nous avons une place de chef de projet à pourvoir. Seriez-vous disponible ?
— Désolé, m’dame, mais ça ne m’intéresse pas. Indépendant je suis, indépendant je reste. Vous savez, détective freelance, ce n’est pas un métier, c’est un mode de vie.
— Bon. Si vous changez d’avis, n’hésitez pas à me contacter.
— J’y penserai. Je vous enverrai ma facture d’ici demain.

Tout en m’installant derrière le volant ma fidèle guibarde, je sortis mon agenda et vérifiai mon emploi du temps du reste de la semaine. Rien. Parfait, j’allais pouvoir partir en vacances quelques jours. Je l’avais bien mérité.

Mais au fond, qu’est-ce qu’un mauvais développeur ? Intuitivement, nous savons les reconnaître quand nous les voyons (ou quand nous voyons leur code).

Parce que bon, le mauvais développeur, il doit écrire un programme, et ben, il code, tandis que le bon développeur, il doit écrire un programme, bon… il code. Mais bon, c’est un bon développeur^[1]

Bref ! Nos étudiants apprenti-développeurs, s’ils apprennent parfois ce qu’il faut faire, n’étudient pas encore assez ce qu’il ne faut pas faire. Et le résultat peut devenir dramatique. Car les mauvais développeurs ont une facheuses tendance à…

Recoder ce qui existe déjà

La première marque du mauvais développeur, c’est de vouloir absolument recoder ce qui existe déjà. Pourquoi vouloir utiliser les fonctions de tri des bibliothèques standards, alors qu’il est toujours plus amusant de (mal) recoder un tri à bulles ?

Après tout, coder est une activité hautement amusante. Ce serait dommage de se priver de longues heures de plaisir en réutilisant des fonctions qui ont déjà été testées, optimisées par des milliers de personnes.

En plus, recoder l’existant augmente considérablement les chances de voir apparaitre des bugs. C’est bien, ça permet de vendre des extensions de garantie.

Écrire un code illisible

Le pire, avec les mauvais développeurs, c’est qu’ils sont en général convaincus d’être bons. Et pour bien montrer leur grosse intelligence, ils n’hésitent pas à produire le code le plus compact et le plus illisible possible. Un peu comme ces philosophes qui emploient des phrases de 10 lignes et sont fiers de n’être compris que d’une élite.

On a dit au mauvais développeur qu’un bon code était un code OP-TI-MI-SÉ. Alors, il optimise, persuadé que l’espace disque qu’occupe son code est un critère à prendre en compte.

Et vas-y que je te rajoute des affectations dans les conditions. Et vas-y que je t’imbrique les opérateurs ternaires (?:). Et allez, une belle expression booleenne à trois niveaux sur une seule ligne.

Le résultat, bien entendu, c’est un code illisible, incompréhensible, et immaintenable.

Puisqu’il en est aux optimisations, le mauvais développeur va également tenter de concevoir le code le plus complexe possible, parce qu’un code complexe est forcément meilleur qu’un code simple. Les codes simples, c’est pour les neuneus qui ne savent pas coder.

// Parce qu'il serai trop simple d'écrire ceci :
if(adresseValide( $adresse ) && adresseDispo( $adresse )) {
    // traitement
} else {
    // Autre traitement
}
 
// Le mauvais développeur préférera ajouter quelques tests et conditions, pour être bien certain de gérer toutes les erreurs possibles :
if(($eAdrel = CompteUtil::VerifierDispoAdrel($d[champAdrel])) != COMPTESADREL_DISPO || ($eAdrel = VerifFormUtil::checkExistingEmailAddress($d[champAdrel]) ? COMPTESADREL_PRESENTE : COMPTESADREL_DISPO) != COMPTESADREL_DISPO) {
...

Bien entendu, si ligne par ligne, le mauvais développeur compacte au maximum, il n’hésite pas en revanche à écrire des fonctions qui dépassent allégrement les 350 lignes. Parce que, c’est bien connu, plus une fonction est complexe, plus elle est puissante.

Écrire beaucoup de commentaires

Le mauvais développeur, persuadé d’être bon, a entendu dire que les bons développeurs inséraient des commentaires dans leur code. Alors il en rajoute. Mais il en rajoute tellement, que ses commentaires deviennent des romans que ne renieraient pas Proust.

/* À FAIRE: éclater cette requête.
 * Le problème est que le traitement fait par nous n'est pas monstrueux,
 * et se fait facilement dans la transaction qu'on lui donne. Cependant
 * derrière, on a des manips eZ publish, inclues dans notre transaction,
 * susceptibles de gros brassages.
 * À l'origine, on travaillait compte par compte. Le problème est que
 * désormais, il peut y avoir des sauts façon attaque de convoi: un
 * compte secondaire peut vouloir profiter de la transition pour se
 * détacher de son principal. L'atome n'est donc plus le couple
 * [compte principal;abonnement]. La solution d'origine ne marche
 * plus.
 * À l'heure actuelle, il reste encore possible de découper par 
 * abonnement de départ (une transaction par abo, plus une par
 * nouvel abo): en effet, on a du:
 * a1 <-1-n-> c <-1-0,1-> a2
 * donc pas de recoupement du moment que ce n'est pas du:
 * … 1-n-> a2
 * (qui permettrait de passer d'un a1, via un c et un a2, à un autre c
 * lié à un a1 différent du premier, autrement dit impossibilité de
 * trancher. Certes, c'est improbable qu'on permette un jour à deux
 * gusses de décider de se lier dans un même abonnement)
 * Autre piste: faire une transaction par compte, et à la fin une
 * grosse transaction sur les abonnements. Comme ça, au pire, s'il y a
 * une erreur à un moment, un certain nombre de comptes auront été
 * placés, et les abonnements seront restés dans leur état d'origine. Ce
 * qu'il faut vérifier alors est qu'on peut effectuer plusieurs fois la
 * passe de multipositionnement sans artefact (ex.: il ne faudrait pas
 * que ça incrémente un compteur, sinon, si on met trois échecs avant de
 * passer, le compteur aura été incrémenté trois fois pour une seule
 * transition d'abonnement.
 */
/* À FAIRE: permettre, par un biais que je n'imagine pas encore, à un
 * compte secondaire qui a demandé son détachement, de quitter
 * prématurément son abo d'origine pour fonder le sien propre. Sinon
 * il est obligé d'attendre pour profiter de son abonnement en nom
 * propre, que le principal veuille bien expirer. */
/* À FAIRE: repérer aussi les abonnements qui ont récupéré de nouvelles
 * options, trouver leurs comptes (comptes principaux mais aussi
 * secondaires) et rappeler leurs ActualiserGroupesComptesEz . */

C’est clair ? (Pour info, ce machin est vraiment tiré d’un vrai projet). Quand on doit se taper du code qui contient 20 lignes de commentaires toutes les 3 lignes de code, c’est… Comment dire ? Lourd ?

En plus, étant donné que son code est bardé de commentaires, le mauvais développeur se considère relevé de l’obligation d’écrire un code significatif. Le code auto documenté, c’est pour les débutants. On se retrouve vite avec des variables et fonctions qui ne signifient plus rien.

$paye = CompteUtil::ModifierEntree(PT.'produit', $restes[0]) ? 1 : COMPTES_EINTERNE;

C’est limpide, non ?

Optimiser à mort

Le mauvais développeur, on l’a dit, adore montrer sa grosse intelligence. Et pour bien montrer qu’il est un pur, un dur, un bon, il optimise son code. Sans doute parce qu’à l’école, il a reçu l’enseignement de vieux de la vieille, des gens qui ont commencé leur boulot quand la mémoire coutait cher, et que les processeurs n’exécutaient que quelques centaines d’instructions par seconde.

Forcément, à cette époque, quand on gagnait quelques octets, quand on économisait quelques instructions, on était content. Mais aujourd’hui ?! Aujourd’hui, ça rime à quoi d’écrire un code tordu pour économiser trois octets de mémoire ? Quel est l’intérêt de déployer des astuces de programmeurs pour gagner 1.10^-1000000000 secondes en temps d’exécution ?

Le mauvais développeur est également un gros fainéant. Pas dans le (bon) sens où il préfère réfléchir 5 minutes pour écrire le moins possible, mais dans celui où il compacte à mort ses instructions pour gagner trois caractères.

for($i = 0; ++$i <= 2;)
...
return array_key_exists(ABO_ACTIF, $etats) ? COMPTESADREL_PRESENTE : (array_key_exists(ABO_LATENT, $etats) ? ($aboFuturAvecCompte ? COMPTESADREL_FUTURE : COMPTESADREL_DEMANDEE) : (array_key_exists(ABO_FINI, $etats) ? COMPTESADREL_DISPO : COMPTESADREL_DISPO)); // Finalement, c'est une mauvaise idée de renvoyer COMPTESADREL_PASSEE: ça bloquerait un internaute ayant oublié de renouveler son abonnement et voulant se réabonner dès le lendemain. On renvoie donc COMPTESADREL_DISPO dans ce cas aussi.

Merci pour celui qui passe après.

Bref ! Il est beaucoup plus facile d’être un développeur moyen qu’un excellent développeur. En revanche, j’en connais qui ont élevé la médiocrité au rang d’art, s’assurant pour jamais un sentiment de haine de la part des autres développeurs qui assurent la maintenance de leurs erreurs horreurs.

Notes :

1. Attention, une référence culturelle se cache dans ce paragraphe. Saurez vous la retrouver ? [retour]

Imprévisible, implacable, inexpugnable, il surgit au pire moment : 30 minutes avant la quille, au moment même ou le malheureux développeur, entrapercevant la fin de la journée, lance ses dernières forces dans sa tâche en cours dans l’espoir de pouvoir rentrer chez lui vivre un peu s’il termine à l’heure.

Mais voilà, le bug de 17h30 est particulièrement sournois. Et le développeur est vulnérable : fatigué nerveusement, éprouvé mentalement, son niveau de concentration, durant l’après-midi, a chuté aussi spectaculairement que monte le prix du baril de pétrole, pour se retrouver aussi bas que le niveau intellectuel d’une émission de TF1.

Dans ce pitoyable état, le développeur n’est plus bon à grand choses. Pressé par le temps, il essaye de se concentrer sur la seule et unique tâche qui le sépare de la fin de sa journée et d’un repos bien mérité. La tête dans le guidon, il enfile ses oeillères et tente de rassembler ce qu’il lui reste de facultés intellectuelles sans se laisser déconcentrer par l’agitation naissante de cette fin d’après-midi.

Mais alors que la fébrilité du développeur est à son comble, alors qu’il semble sur le point, pour une fois, de réussir l’exploit de terminer sa journée à l’heure, surgit brusquement le terrible bug de 17h30. Il fond sur le développeur comme un rapace sur sa proie, le prend au dépourvu, le heurte comme un uppercut qui le laisse pantois, sans souffle et sans voix.

Le développeur, expérimenté, comprend vite à qui il a à faire. Rompu à l’art de l’algorithmique, endurci par son expérience riche en longues sessions d’intense débuggage, il n’entend pas se laisser abattre par le premier message d’erreur venu. Son sang gorgé de cafféine ne fait qu’un tour. Déterminé à en découdre, il se jette corps et âme dans la bataille numérique. À la fin, il n’en restera qu’un seul.

À ma gauche, le développeur. 1m75, 70 kilos, 5 années d’études et 15 ans d’expérience sur le terrain. À ma droite, un message d’erreur sibyllin annonçant un dysfonctionnement du programme.

Le combat commence. Le développeur commence par un message de débug pour localiser le problème. Le programme répond par un segfault. Le développeur vide les caches. Heap overflow. Il installe l’extension manquante. Fatal error : Call to a member function on a non-object. Il tente un cvs update. Failed to open stream !

Bing ! Paf ! Vlan ! Les coups pleuvent de toutes parts. Et pendant ce temps, le développeur voit, de plus en plus paniqué, l’horloge qui avance, inexorablement. Déjà son rêve de rentrer chez lui à l’heure s’envole. Finalement, en l’espace de quelques minutes, il a l’impression qu’une journée entière s’est écoulée. Il a vu passer tous les messages d’erreurs imaginables, et en a même découvert de nouveaux, inconnus jusqu’alors.

Le développeur est loin d’être un incompétent, et il s’est battu honorablement. Mais la lutte, trop inégale, était perdue d’avance. Résigné, il comprend que son programme, malgré tous ses efforts, ne tournera pas ce soir. À 18h55, épuisé, pantelant, couvert de l’aigre sueur de la défaite, il n’a d’autre choix que d’abandonner, en songeant que de toutes façons, sa copine lui passera un savon.

Tête basse, il se décide à tout laisser en plan. Il ajoute un dernier commentaire pour retrouver facilement l’emplacement du problème le lendemain, fait disparaître son éditeur préféré d’un :q ! rageur, se déconnecte de ses quelques consoles ssh, et fini par éteindre sa machine, le coeur lourd, l’âme en peine. Vaincu !

Le lendemain, frais, dispos, l’esprit clair, il découvrira l’origine du problème en une minute, et le corrigera en cinq. Car le terrible bug de 17h30 n’est généralement qu’une pécadille, un point-virgule manquant, une erreur d’index, une variable non affectée, une inversion de casse.

Après coup, le développeur se demandera comment une erreur aussi stupide, aussi évidente, a pu lui résister aussi longtemps. Il en rira, et amusera ses collègues, autour de la machine à café, en leur racontant son épopée. Mais au fond de lui, demeurera toujours cette hantise, cette angoisse qui apparaît lorsque l’aiguille approche de cette horaire fatidique : 17h30. L’heure des bugs.

Une autre demi-journée pour diagnostiquer une erreur de cache.

Bilan de la journée : une migraine et 5 lignes de code.

J’aime pas les lundis.