Linux Attitude

Niveau :      
Résumé : écrire, réécrire

Factoring

Supposons que vous développiez un projet personnel. Vous êtes le seul à spécifier les besoins, le seul à spécifier l'architecture, le langage ... Malgré cela vous constatez la plupart du temps que le résultat est moyen, voire médiocre (ou acceptable si vous êtes très doués). Pourquoi ? Simplement parce qu'un programme doit toujours être développé au moins deux fois.

Vous devez être conscient que la première version d'un programme sera toujours un prototype. Sans exception. Mais cela va me coûter cher me direz-vous ! Hé bien pas tant que ça. Puisque vous êtes conscients que la première version sera un prototype, vous y mettrez beaucoup moins d'efforts. D'autre part la deuxième version sera plus courte à écrire puisque vous avez acquis toute l'expérience nécessaire. Et enfin les bugs de conceptions, les plus durs à résoudre, pourront être évités et donc vous gagnerez du temps.

Un prototype c'est un programme qui a toutes les fonctionnalités du produit fini (ou presque, les demandes évoluant souvent en cours de route). Mais il n'intègre pas nécessairement tous les détails, toutes les options ou une interface graphique soignée. Un prototype ne doit pas être la base de la version suivante du programme. La version finale doit être repensée en partant de 0 (on pourrait même dire que le langage doit être changé). Par contre, rien n'interdit de faire du copier/coller depuis le prototype vers la version finale, c'est même recommandé car un grand nombre de fonctions ont déjà été développées correctement.

Vous aurez compris que ce que je viens de vous décrire est le refactoring. Rien de bien nouveau, seulement vous devez être conscient que pour faire un logiciel dans lequel vous ne perdrez pas votre temps, vous devrez refactorer au moins une fois.

Refactoring

Maintenant , si vous développez pour une entreprise, le processus de développement est quasiment toujours le même. Un client a fait un cahier des charges plus ou moins complet, assisté d'un commercial qui en a profité pour lui faire de nombreuses promesses. Ensuite ce cahier des charges a été traduit par un analyste (peut-être vous même) en un schéma d'architecture ou un schéma UML avec des use case pour les plus méticuleux. Très bien, on pourrait aller jusqu'à dire que c'est fait dans les règles de l'art. C'est ici que le boulot de développeur (et les ennuis) commence. Il s'agit de prendre l'analyse et d'en faire, presque mécaniquement, le logiciel désiré.

Et vous en avez tous fait l'expérience, ça ne marche jamais comme il faut. Il y a de nombreux endroits où le bât blesse. Tout d'abord le client ne sait pas ce qu'il veut, normal il s'agit d'un produit qu'il n'a jamais vu ni utilisé. Ensuite le commercial en a profité pour lui vendre quelque chose de génial, normal c'est son boulot, mais pas nécessairement réalisable. Ensuite l'analyste a fait ce qu'il a pu pour déduire de ce cahier des charges écrit en langage courant un schéma qui peut être informatisé. Et enfin le développeur fait ce qu'il peut en fonction des contraintes du langage utilisé.

C'est le même cas que précédemment, en légèrement plus compliqué surtout s'il y a beaucoup d'intervenants. L'extreme programming pallie ce problème en prônant un refactoring permanent et un bouclage fréquent avec le client.

Ne perdez plus votre temps, mettez des bouts d'extreme programming dans votre activité.