Développer : théorie et pratique

Ça fait déjà quelques années que je me fais des réflexions hautement philosophiques (sic) sur le développement de logiciel. J’ai goûté au joies du Basic, quand j’avais une quinzaine d’années, c’était il y a environ 35 ans, puis du C, du Fortran, un peu de Pascal et de Cobol, de l’assembleur pour optimiser quelques fonctions, et quelques langages probablement oubliés depuis comme le PLM/86 et quelques parenthèses de Lisp, etc etc. Depuis toutes ces années j’ai appris que la pratique commandait la théorie.

Je m’explique.

J’ai pour la plupart de mes développements été contraints par des impératifs de durée, de délai, de coût. Ces impératifs sont fréquemment incompatibles avec la belle écriture de code. Je n’ai pas eu souvent le temps de factoriser, de créer de belles librairies qui pourront resservir un jour et lorsque je l’ai fait elles n’ont jamais été réutilisées, simplement parce qu’entre temps l’environnement de développement avait changé, quand ce n’était pas le langage ou le système cible. Bref, ça a souvent servi à … rien. Sauf à une chose : apprendre à factoriser et à créer de belles librairies bien écrites. Et j’avoue humblement ici qu’il m’est arrivé de réécrire de A à Z un code, simplement parce qu’à force de rajout et correction il devenait moins élégant. Que voulez-vous, j’aime le code bien écrit, même si j’avoue que ça reste très subjectif.

Depuis quelques années je développe en PHP pour Dotclear. Je crée les fonctions dont j’ai besoin ou que d’autres réclament pour leurs propres usages. Dans ce domaine du logiciel libre j’ai aussi remarqué qu’on faisait très peu de factorisation, de mise en commun de code, chacun développant les routines dont il a besoin, au moment où il en a besoin. J’ai aussi remarqué une constante propension chez les codeurs à développer du code pour le okazou.

Le okazou est une drôle de bestiole insatiable qui réclame sans cesse de nouvelles choses, okazou. Dernièrement j’ai vu l’annonce d’un développement et l’enthousiasme des autres codeurs de la communauté. Fort bien me suis-je dit et puis ensuite ? Eh bien il y a eu quelques idées lancées ici et là, utilisant cette nouvelle fonctionnalité et depuis plus rien. Plus rien parce que ceux qui ont codé et ceux qui se sont félicité de la nouveauté n’en auront probablement jamais l’usage.

Ne pas respecter le concept YAGNI est un anti-pattern. le concept YAGNI dit qu’il ne faut pas implémenter maintenant quelque chose qu’on pense sera utile plus tard.

[ Source : Wikipedia ]

J’ai probablement une façon très empirique d’envisager mon métier (en tout cas une partie de mon métier). Je code, je développe ce dont j’ai besoin, parfois en adaptant du code repris ailleurs. J’enrichis si nécessaire au fur et à mesure de l’avancement et il m’arrive de reprendre une partie de mon code pour le rendre plus lisible, plus facile à maintenir. Quant à la documentation, si elle n’est pas écrite au moment du développement eh bien je l’oublie. Volontairement. Par contre il m’arrive très régulièrement de faire de la doc, ou en tout cas d’écrire quelques lignes d’explication, à propos du code d’autrui, c’est très instructif et j’ai souvent appris beaucoup de cette manière.

Ce que j’ai constaté et expérimenté dans le domaine professionnel est tout aussi valable dans le logiciel libre. Les contraintes diffèrent, certes, mais il en existe et parfois des sévères. Pensez bande passante, place disponible, empreinte mémoire, etc qui sont tout autant de curseurs qui viennent contraindre vos développements.

Finalement ce que j’ai appris depuis tout ce temps passé devant un écran est qu’il faut savoir ne pas factoriser, qu’il faut savoir faire du sur-mesure, du code qui ne sera jamais réutilisé. La pratique m’a souvent conduit à faire des raccourcis, des impasses et parfois même à faire du code sale parce que c’était le plus efficace. Idem pour la doc — je ne parle pas des commentaires intégrés au code source, mais des documents externes — que j’ignore superbement. Vous n’imaginez pas le temps que j’ai gagné à ne pas m’en préoccuper sachant qu’il est moins couteux pour moi de me replonger dans le code et de recomposer sa structure mentalement, voire en prenant quelques notes sur papier, lorsque le besoin s’en fait sentir.

Certes ce que j’explique ici ne concerne que moi, que ma façon de travailler parce que je bosse fréquemment en solitaire, même sur des projets en commun, parce que les champs d’intervention sont délimités, bornés. Du reste je n’ai pas constaté de véritable travail d’équipe dans les projets de logiciels libres que j’ai approché, certainement moins d’ailleurs que lors des quelques projets auxquels j’ai participé quand je travaillais en SSII. Je ne prétends pas non plus avoir tout vu dans ce domaine, loin de là.

La pratique commande la théorie disais-je en introduction. Ça fait quelques décennies que je le constate et malgré tous les progrès et évolutions rencontrés au fil des années, ça reste vrai. On change de langage, de structure, d’environnement, hier PHP, aujourd’hui Python, demain d’autres langages émergeront et il faudra encore et toujours adapter sa théorie à sa pratique. On peut appeler ça du pragmatisme ou de l’économie.

Je me souviens de ce qui m’avait plu dans Dotclear, au moment où, alors que je cherchais à remplacer le forum personnel qui me servait de site internet, j’avais lu sa fiche sur Framasoft : « Dotclear : Il ne s’occupe que de blog mais il le fait bien »[1]. Voilà qui était tout à fait compatible avec ma façon d’envisager un développement, faire une chose et la faire bien. D’ailleurs je fais plus souvent confiance à un logiciel mono-tâche qu’à une suite logicielle.

Pour résumer, je code de manière minimaliste mais suffisamment propre pour ne pas avoir à en rougir quand je l’expose. J’en attends autant des outils que j’utilise, du code que je mets à contribution, des logiciels que j’emploie.

Et vous ?

Notes

[1] Ce ne sont pas les termes exacts mais j’avoue avoir perdu la citation originale.

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Haut de page