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 !

4 commentaires:

metagoto a dit…

Une autre possibilité à envisager:

4. Il est plus compétent que moi...

Finalement ce qui parait absurde peut s'avérer être une idée de génie. Rare mais pas impossible. Des tricks ou idiomes peuvent naître de codes au demeurant absurdes. Par exemple les CSS hacks ou les X-macro de C.

Etre humble dans le développement. Nous sommes d'accord.

Gauthier Delamarre a dit…

merci pour ta contribution metagoto ; j'avoue que je me sens un peu tout bête d'avoir omis cette situation, alors pourtant qu'il m'arrive fréquemment d'admirer des bouts de code, notamment lorsque je consulte les sources de Zend Framework, qui remplacent pour moi avantageusement sa documentation dans la plupart des cas ;)

Olivier Mansour a dit…

On peut aussi dire qu'il l'a fait a une époque ou les normes et les pratiques étaient différentes. Voir les capacité du langage. (exemple : migration d'un projet PHP4 à PHP5).

Gauthier Delamarre a dit…

@Olivier ça fait plaisir de voir qu'il reste des gens optimistes sur cette planète :) Toutefois, je dois bien reconnaître que j'en suis revenu... dans l'immense majorité des cas, les développeurs ne se défont jamais des très mauvaises habitudes contractées durant cette sombre époque de l'histoire de PHP.

Mais je pense que ceci fera l'objet d'un prochain post ;)