Archives mensuelles : mai 2011

La phase la plus importante d’un projet : le polissage

Si vous êtes comme quoi, cela vous est probablement déjà arrivé de regarder votre application et de vous dire « mais comment se fait-il que cela fait six mois que je travaille la dessus ? Je pourrais tout refaire en trois semaines. ». Ou peut-être avez vous déjà largement sous estimé une tâche, sans qu’aucune difficulté ou méconnaissance de la vélocité des collaborateurs soit en cause. Ou encore vous avez du faire face à l’incompréhension d’un interlocuteur (souvent junior) quand vous lui donnez l’age du projet et qu’il se fait la même réflexion (« je pourrais le faire en … »).

Sans parler de la connaissance du sujet et de l’expérience qui permet, en effet de refaire la même chose plus vite, une application pour être vraiment présentable a besoin d’un temps de pollissage. C’est ce travail qui sépare vraiment un POC, ou plus généralement un projet commencé à l’arrach d’une vrai application professionnelle.

Ne jamais faire en dev ce qu’on ne veut pas voir en prod

La plupart du temps (et c’est d’heureux), les développeurs d’applications, de sites, travaillent sur un environnement de développement, le plus souvent leur propre machine. Ce qu’ils y font n’est visible que d’eux même et de quelques privilégiés de la même équipe.

Comme le travail d’ingénieur peut être ennuyeux et que les développeurs ne sont pas dénués de sens de l’humour (même s’il peut être particulier), la tentation d’ajouter dans l’application en cours de développement ou dans ses ressources une petite blague peut se présenter. Cela peut prendre la forme d’une image ou d’un message amusant (pour celui qui l’ajoute du moins), en encore d’un easter egg.

Il peut également arriver que le travail soit frustrant ou énervant. Et là on a des commentaires désobligeant pour son boss, le navigateur, l’équipe MOA, …

On a par exemple la gaffe récente d’un développeur travaillant pour TF1 traitant de « Couillons » les internautes cliquant sur les publicités ou encore les commentaires HTML insultants IE6 dans les commentaires HTML d’une page.

L’auteur n’a cependant certainement aucune envie de voir ce genre d’exploits en production, alors comment cela arrive-t-il ?

D’abord, la séparation est parfois mince entre ce qui est visible par l’utilisateur et ce qui ne l’est pas.

Prenons par exemple la différence entre les commentaires JSP et les commentaires HTML :

<%– Tableau de présentation à cause de ce #@$§! d’IE6–%> Commentaire JSP, non visible dans le HTML final
<!– Tableau de présentation à cause de ce #@$§! d’IE6–> Commentaire HTML, visible dans le HTML final

A deux caractères près, on a des grossièretés visibles par tout le monde.

On peut aussi avoir des problèmes avec la configuration des environnements :`

service-externe1.url = http://prod.service.com/service1
service-externe2.url = http://test.service.com/service2
service-externe3.url = http://prod.service.com/service3

Une URL de test est restée dans le fichier de propriétés de l’environnement de production. Cela peut prendre du temps à être vu si le service ne sert pas souvent.

On a aussi, comme dans le cas de TF1, la possibilité que d’autres informaticiens s’intéressent à l’application et décompilent le code, par exemple flash, ou les fichiers .class s’ils y ont accès.

La conclusion est implacable : Ne jamais faire en DEV ce qu’on ne voudrait pas voir en production.

Pourquoi la programmation se fera toujours avec du texte

Les applications modernes sont en général composées de plusieurs parties, écrites dans des langages différents. On a du java, du xml, du json, d’autres langages encore.

Dans tous les cas le texte prédomine.

Il arrive pourtant parfois que le logiciel s’appuie sur des composants non textuels. J’ai déjà vu la couche présentation programmée en base via une interface graphique ou encore des règles métiers stockées dans des fichiers excel (drools le permet).

On peut aussi imaginer écrire les programmes de manière différente, par exemple en dessinant de l’UML, en décrivant les algorithmes par l’exemple de manière graphique, en faisant des flèches pour les mappings, en imbriquant des boites les unes dans les autres à la manière des paquetages.

Bref utiliser autre chose que du texte.

Mais ce n’est vraiment pas pratique.

Si le texte prédomine dans la programmation, il y a une raison, autre qu’historique : les outils. Tous nos merveilleux outils sont conçus pour fonctionner sur du texte, et font en général des choses formidables avec.

Du texte ça peut se versionner, et surtout se comparer avec des outils permettant de voir les différences entre les versions. On peut aussi y faire des recherches de chaînes, via nos IDE ou la commande grep. On peut lire du texte sur l’importe quelle plateforme, avec des dizaines d’éditeurs différents. Il y a assez peu de problèmes de compatibilité, puisque la source est toujours du texte simple, lisible via vim ou le bloc notes. On peut faire de copier/coller, des remplacements de chaînes, du reformatage. On peut analyser tout ça avec des outils comme PMD. On peut utiliser des compilateurs différents avec le même code source. Et cetera.

Comparer des documents office versionnés avec SVN ou Git ne sert à rien (c’est du binaire).

Une recherche de texte ne permettra jamais de trouver le code métier qui apparaît dans la stack, parce qu’il est planqué dans le fichier excel de règles.

Pour ces raisons, aucune autre manière de programmer que par le texte ne s’est popularisée ni ne se popularisera.