Ç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.
1 De lipki -
Et bien disons que j’aurais écris ce texte si je savais écrire.
Où plutôt j’écrirais ce texte quand je saurais écrire et que j’aurais acquis plus d’expérience dans mon métier (qui est le tiens).
Où pour faire court : +1
En ce moment je passe de la méthode OKAZOU à la méthode YAGNI.
Mais bien sûr sans oublier les fondamentaux, tous coder à l’ARRACHE.
2 De nicofrand -
C’est plutôt le même cas de figure pour moi, hormis pour la documentation : je la lis avec précaution, et ce d’autant plus si la complexité du code (ou son illisibilité parfois) est forte.
3 De mirovinben -
Et moi ? Pareil. Sauf que je n’ai pratiqué que le Basic (interprété dans un premier temps (à partir de 1982 Basic sur Comodore64, à partir de 1985 GW basic sur PC) puis compilé dans un second temps avec le Turbo Basic) et le Pascal (Turbo Pascal puis Delphi) avant de tâter du PHP plus récemment (Dotclear).
Sinon, rien à voir mais également dans le billet : 15 + 35 = 50 environ. Très environ non ?
4 De biou -
en fait tu faisais de l’agile sans le savoir et surtout avant que ça existe !
Chez eux aussi le OKAZOU est interdit et on peut faire du code pas trop réutilisable étant donné qu’il est fort probable qu’on le jette à la prochaine itération.
Je me dis que ces règles doivent un peu s’appliquer aux langages/environnements aussi. Il est plus facile d’avoir cette approche avec un langage facile à appréhender comme PHP, qu’en java / j2ee où il faut déjà 2 semaines rien que pour configurer le projet avec sa toute jolie architecture… /troll
5 De Franck -
Bon me voilà bien rassuré sur ma façon de faire !
mirovinben tu comptes pas si mal en fait :-) Mais je ne les ai pas encore, j’suis encore très jeune :-p