Pour réduire nos temps de développement, commençons par les augmenter
Pourquoi réutiliser l’existant quand on peut réinventer la roue ? Ça fait maintenant 6 ans que je développe pour diverses entreprises, et je n’ai jamais trouvé de réponse à cette question.
Le fait de commencer régulièrement de nouveaux projets signifie visiblement reprendre toute une application depuis le début, quand bien des sites Web, par exemple, ont un certain nombre de points en commun.
J’y vois à première vue trois raisons :
La première tient d’une sorte de « erase and rewind » intellectuel, qui veut que l’on reparte d’un canevas neuf pour chaque nouveau projet. J’ai remarqué ce reflex au sein d’entreprises n’utilisant que peu ou pas de logiciels open source, que ce soit dans leur fonctionnement interne ou comme base de leur développement.
La seconde est purement commerciale, et consiste à justifier les temps de développements cotés au moment de la rédaction du devis. Je ne crois pas qu’elle se justifie dans le cadre d’une prestation en forfait, pour laquelle une application complète est vendue : si le développeur peut travailler plus longtemps, le client est en échange servi moins rapidement, pour un résultat semblable. Dans le cadre d’une prestation en régie, ne pas réinventer la roue permet pour un budget identique d’augmenter les temps de mise en recette et de qualification, assurant par là une application de bien meilleure qualité
La troisième raison est purement technique : ne pas réinventer la roue sous entend soit adapter un existant à un environnement donné, soit accepter de développer des tranches d’applications parfaitement modulaires, et, si possible, interopérables autour d’une API préalablement difficile. Dans le premier cas, la surcharge de travail est difficile à évaluer avant une première utilisation d’un existant donné. Dans le second cas, les délais de développement sont souvent plus longs, le temps de développer un module répondant à un besoin donné : news, faq, carnet d’adresses… tout cela devant être indépendant, et facilement intégrable à la fois.
Dans le cadre d’applications Web, la difficulté ne vient généralement pas de l’application elle-même, mais plutôt du rendu. Doit-on faire une simple sous couche générant les données voulues au moment voulu, un le module doit-il aussi gérer l’affichage au risque de ne pas correspondre avec la charte graphique élaborée à grands frais par le service marketing ? Comme diraient les Shadocks, s’il y a un problème, il y a une solution, et s’il existe une solution, alors il n’y a pas de problèmes. La solution au notre réside dans un markup sémantiquement réfléchi, léger, et laissant l’affichage reposer entièrement sur du CSS. Simple mais terriblement efficace.
Pour résumer ce cours d’énumération d’évidences pourtant pas si évidentes vu ce que j’ai pu rencontrer ces 7 dernières années :
- Développez de manière modulaire, c’est plus long la première fois, quasiment instantané la seconde.
- Allégez votre markup autant que possible. Pensez à la sémantique.
- Laissez CSS faire l’affichage, c’est son boulot, pas celui du XHTML.
À propos
Je m'appelle Frédéric de Villamil, et quand je ne déploie pas ma mauvaise humeur et ma mauvaise foi sur le Web, je suis un super héros chargé de sauver le monde. Vous pouvez me suivre sur Twitter.
À lire également
Si Pour réduire nos temps de développement, commençons par les augmenter vous a intéressé, vous pouvez poursuivre votre lecture avec ces billets similaires :
1 commentaire sur Pour réduire nos temps de développement, commençons par les augmenter »
-
JS le 31 janvier 2006 à 23h08
Tu prêche un convaincu.
Lors de mon ancienne mission, j’ai “réorganisé” un site permettant à des propriétaires de proposer leurs biens immobilier à la location. J’y ai passé pas mal de temps. Mais ensuite, pour créer un nouveau site web ciblé sur une région, un domaine skiable où n’importe quoi, il me faut 15 minutes (sans compter le boulot du graphiste bien sur).
En 2 jours j’avais lancé 4 nouveaux sites, tous optimisés pour le référencement, et j’avais épuisé le boulot de la graphiste :)
Maintenant, dans ma nouvelle mission, nous faisont du développement de sites sous Plone. Un seul mot d’ordre : réutilisabilité (reuse in english, bien plus simple à écrire comme mot). Et il faut dire que Zope, Plone et autres sont bien orienté “modules” donc ça aide. Surtout que l’on peu appeler un module et lui appliquer un “skin” différent à chaque fois. Donc l’intégration dans le site est parfaite.
Réagir à Pour réduire nos temps de développement, commençons par les augmenter
Trackbacks sur Pour réduire nos temps de développement, commençons par les augmenter
Les trackbacks sont fermés pour cause de spam.
