Dessine moi un logiciel

Ecris le 11 décembre 2007
Dans la catégorie Articles |

Choisissez un collègue informaticien, n’importe lequel, qu’il porte le titre de développeur, d’architecte, d’urbaniste ou de manager. Demandez-lui de dessiner une application informatique.

Il y a toutes les chances que le dessin qu’il vous fera sera constitué de boites, de flèches, et peut être de cylindres. Tous les livres, toutes les méthodologies d’architectures ou d’urbanisme reprennent ce même type de schéma. Certains en ont mêmes fait une science en tant que telle. Il existe autant de types de boite que d’applications. J’ai résumé pour vous ceux que je croise les plus souvent : base de données, écrans, couche service, framework techniques, socle d’échange, gestion des authentifications, référentiel, gestion des habilitations, mapping objet-relationnel, moteur de workflow, etc… etc…

Dés lors que nous avons fait ce constat, nous ne sommes plus surpris par la manière dont sont construites les applications dans la vaste majorité des cas. L’équipe, ou le manager, choisit une boite et commence à l’implémenter. Il commence par exemple par la base de données. Puis il passe à la suivante. Puis une autre. Jusqu’à ce que toute l’application ait été construite. Ce chemin de construction est parfois résumé dans un diagramme de Gantt.

Cette approche présente l’avantage d’être facile à comprendre, par tout le monde. Elle est facile à expliquer et donne le sentiment d’être facile à suivre, facile à piloter.

Elle présente aussi des inconvénients :

L’application n’est pas fini tant que toutes les boites et cylindres n’ont pas été implémentés
Si le design d’une boite en cours de construction est influencé par le design d’une boite à venir, il y a toutes les chances que cette dépendance soit découverte plus tard, trop tard.
Il est difficile de tester l’application tant que toutes les boites n’ont pas été construites.
Certaines boites vont se révéler inadaptées dans la suite du projet. Il sera plus difficile de les remodeler si elles sont totalement achevées avec l’ensemble de leur complexité.

Si vous choisissez de suivre une approche agile pour la construction de votre application, vous aurez le choix de procéder autrement. Vous pourrez bénéficiez d’une caractéristique unique de la “matière” informatique : tout peut changer, tout le temps.

Ralph Johnson nous le rappel dans un article de Martin Fowler :

There is no theoretical reason that anything is hard to change about software.

Plus qu’un jeu d’éléments qui s’emboitent les uns dans les autres, je vois la construction de logiciel comme la création d’un tableau. L’artiste commence par une esquisse. Le sujet est posé et les grandes masses apparaissent. Mais les détails sont encore flous et la finition n’est pas idéale. Puis il rajoute de la peinture, il fait des mélanges pour voir ce que ca donne. Il revient parfois en arrière par endroit, pour mieux garder une harmonie d’ensemble. Petit à petit, le tableau devient de plus en net, plus précis. Jusqu’au moment où c’est terminé.

L’informatique vous offre la liberté de procéder de la même manière pour construire votre logiciel. Vous avez le choix de commencer par l’implémentation de plusieurs boites dés les premières itérations de votre projet. Vous aurez déjà un premier aperçu de votre application. Ce sera un embryon de ce que vous pourrez obtenir plus tard, mais vous pourrez déjà le montrer à vos clients et obtenir leurs feedback. Ils vous diront ce qu’ils aiment dans ce que vous avez déjà réalisé, ce qu’ils souhaitent que vous changiez et ce qui leur manquent. Tenez en compte pour la suite de votre projet.

Puis ajoutez, affinez, complétez votre application. D’itération en itération, votre vision deviendra plus précise et convergera vers le meilleur compromis possible compte tenu du temps impartis, du budget et ce qui apporte le plus de valeur à vos clients. La construction d’application peut être autre chose qu’un assemblage de briques d’un jeu d’enfant. Elle peut aussi être la création d’une image de plus en plus nette, que vous pourrez recadrer, retravailler tout au long de votre projet.

Social Bookmarking