mercredi 18 août 2010

L'humilité, la première des bonnes pratiques ?

Je ne peux pas croire que je sois le seul à qui il arrive, en relisant un code produit par quelqu'un d'autre, de me dire "mais qu'est-ce qu'il a bien pu lui passer par la tête pour écrire quelque chose d'aussi absurde ?". 

A cette question, que je me suis tant de fois posée, et souvent en termes nettement moins châtiés, j'hésite souvent à apporter l'une des trois réponses suivantes :

1. Il était contraint par les délais...

C'est la raison la plus souvent invoquée pour justifier un travail bâclé. Mais l'excuse ne tient pas dès lors que l'on admet que négliger une partie d'un projet, si infime soit-elle, conduira nécessairement à de bien plus lourdes pertes de temps ultérieurement. En effet, un élément du système qui serait soit mal conçu, soit mal réalisé, ou encore mal voire pas testé, bloquera la mécanique tôt ou tard, et rendra d'autant plus difficile l'identification et la correction des problèmes engendrés.

Si l'on n'a pas de temps à perdre, on ne peut s'offrir le luxe de l'improvisation, et c'est précisément dans ce contexte que le respect des bonnes pratiques s'impose plus que jamais. Je pense très clairement qu'il faut, en tant que développeur, avoir l'humilité de ne pas penser que l'on peut faire son travail correctement au mépris de toute bonne pratique. Notez au passage que le développement est bien l'un des rares métiers dans lesquels on tolère ce genre d'attitudes. Un cuisinier qui déciderait de cuire un tournedos au micro-ondes pour gérer un afflux de commandes trop important se verra inviter à rendre son tablier sur-le-champ ! Le délai est une contrainte, mais pas la seule. La qualité est autrement plus importante, car elle conditionne notre capacité à continuer de s'adapter aux délais à plus long terme. Sans oublier la confiance qu'elle permet d'établir puis de maintenir avec les donneurs d'ordre.

2. Il ne savait pas faire autrement...

Le manque de maîtrise des outils et méthodes nécessaires à la réalisation des projets est également un grand classique. A cela il peut y avoir plusieurs raisons. Certains manquent tout simplement d'intérêt pour leur métier, d'autres de discernement quant à leur compétence, et ne se rendent pas vraiment compte qu'ils ne savent pas faire. Dans le premier cas, je ne vois guère de remède. 

Pour les autres, prendre quelques minutes après coup pour s'interroger sur ce que l'on vient de faire, avec un peu de recul, et se forcer toujours à se demander s'il n'y aurait pas d'autres façon d'y parvenir, suffit le plus souvent à corriger dès le début un travail qui sinon ne le sera jamais, et polluera l'ensemble de manière définitive. Solliciter des collègues est également un bon moyen, au travers d'un regard extérieur, de valider ou non ses choix. Enfin, il ne faut jamais hésiter à reconnaître ses lacunes, ou au moins à les envisager (on a parfois de bonnes surprises !), et à exiger d'être formé sur les outils que l'on nous demande d'employer. Je pense particulièrement aux frameworks : des responsables prennent parfois la bonne décision de baser les développements sur un framework sans l'accompagner de l'excellente initiative d'y former ses équipes.  Un développeur est supposé connaître un langage. Maîtriser un framework, même s'il est basé sur ce langage qu'il connait, n'est pas évident, et surtout pas inné. Une formation est un bon moyen d'en prendre possession rapidement, sans contracter de mauvaises habitudes par simple manque de connaissances, que l'on ne peut pas inventer !

3. Il n'est pas développeur, il est soudeur à l'arc

Ceci expliquant cela... 

Conclusion

Trêve de plaisanterie, aborder son métier avec humilité me semble être une nécessité absolue si l'on a la naïve mais essentielle ambition de continuer de progresser. Etre humble ne signifie pas douter de soi, et encore moins s'imposer de penser que ce que l'on fait n'est pas bon. Cela signifie être conscient que l'on peut toujours se tromper, et qu'il faut rester vigilant. Qu'il ne faut jamais douter que d'autres peuvent avoir une meilleure approche d'un problème, et se réjouir d'en profiter plutôt que de se morfondre de n'y avoir pas pensé soi-même, ou pire, rejeter en bloc et n'en faire qu'à sa tête. 

Enfin, être humble dans le développement, c'est aussi se rappeler que ce que l'on fait n'est pas une fin en soi, mais a pour vocation de soutenir un activité commerciale, associative, éducative... En gardant cela à l'esprit, on évite plus facilement de tomber dans le piège du "troll", ces fameux débats stériles et partisans infiniment nuisibles à la qualité du travail produit, mais aussi aux conditions dans lesquelles on le fait !

mardi 17 août 2010

france.fr

Bon je fais court, très court même. Mais après avoir longtemps résisté, tant c'était facile, et de fait presque indigne, je craque.

On pourrait croire que je n'assume pas mon billet sur Drupal (et tout le mal que j'en pense, pour résumer à l'attention de ceux qui ne l'auraient pas lu) si je ne faisais pas la moindre référence au délicieux fiasco qu'a été le lancement (et qui sait, peut-être le développement aussi ?) de www.france.fr.

Pour être honnête, je ne me suis pas plus intéressé que ça à ce dossier. J'ai simplement entendu beaucoup de monde railler abondamment les services de l'Etat avant de découvrir, par hasard soit dit en passant, que ce site avait été développé avec Drupal.

Je n'ai qu'une chose à dire : CQFD !

Série d'interviews sur PHP6

A l'initiative de mon camarade de jeu Frédéric Hardy, une série de plusieurs interviews sur l'avenir de PHP 6 a été publiée sur son blog personnel, que je qualifierais volontiers de professionnel.

Il m'a fait la gentillesse de solliciter mon point de vue sur la question, aussi je souhaitais faire connaitre cette publication car elle me semble tirer le débat un peu vers le haut, et nous donner l'occasion de réfléchir d'une manière un peu plus objective sur l'avenir de PHP.

Bien que je me pose moi-même la question depuis un moment, et qu'il me soit arrivé de m'exprimer sur le sujet, je me suis rendu compte en répondant aux questions de Frédéric à quel point nous pouvions parfois, en tant qu'utilisateurs (entendez "développeurs" naturellement), être très éloigné de la façon dont la plateforme évolue.

Alors j'espère que la lecture de ces différentes interviews vous amènera vous aussi à vous interroger plus avant sur l'implication que nous pouvons avoir dans l'évolution de PHP, en tant que professionnels aussi bien que de passionnés.

Pour ma part, j'en suis arrivé à la conclusion que JFK, qui n'en savait pourtant rien, avait déjà bien résumé la situation, du moins si on s'autorise à le paraphraser : "ne te demande pas ce que PHP peut faire pour toi, mais demande-toi ce que tu peux faire pour PHP".