next up previous contents
Next: About this document ... Up: Introduction à PERL Previous: Perl et le système

Les spec de votre programme

Vous avez lu cette doc, vous en avez lu d'autres, vous voyez grosso-modo ce que Perl peut vous apporter et enfin, vous avez besoin d'un programme, là, ici, maintenant.

Perl est un langage très souple, trop souple diront certains, mais c'est une richesse tout de même, cela permet de réaliser des programmes de plusieurs milliers de lignes ou des scripts de quelques lignes. C'est une force qu'a le Perl et que l'on ne retrouve pas dans les autres langages qui sont, généralement beaucoup plus spécialisiés.

Mais qu'il ne vous prenne pas l'envie d'écrire une application relativement lourde comme vous écrirez le script de dix lignes pour trier un fichier, car la maintenance, voire le debogage de votre application sera impossible. On dira que votre code est " sale ".

Pour cela, il est important de bien faire la différence entre un simple script et une application lourde, le premier fait quelques dizaines de lignes et se suffit à lui même, le second peut faire plusieurs milliers de lignes et être constitué de modules ou de plus programmes plus ou moins volumineux.

Pour la seconde catégorie (mais j'aurais envie de dire pour la première aussi) vous devez impérativement suivre une voix qui a été décidé et tracer dès le départ. Cette voix, c'est le cahier des specs.

Un cahier des Specs n'est pas écrit dans n'importe quel sens, si il doit guider la partie codage de votre projet, il doit lui même est clair et suivre un schéma bien précis que vous aurez pris soin d'établir.

Voici un exemple de plan pour la réalisation d'un cahier de spec, j'utilise ce type de plan pour chacun de mes projets, qu'il s'agisse de programmation en Perl ou de toute autre cas de figure :

1.
État des lieux C'est qu'il convient de mettre a plat la situation actuelle, le besoin, les moyens en place pour le combler et que l'on doit argumenter sur la nécessité de réaliser un programme soit meme.
2.
Langage choisi

Car le Perl n'est pas la solution a tout, c'est ici qu'il convient d'argumenter en faveur du moyen choisi pour remplir le besoin précédement cité.

3.
Les règles

Vous devrez suivre des règles d'écritures strictes que vous définirez ici. Bien sur, je vous conseille de reproduire celle données dans ce livre. Ceci permettra à quiconque reprendra votre code de comprendre de suite votre manière d'écrire.

4.
L'application

Ici, vous décrivez toutes les fonctions de votre programme.

5.
Le plan

C'est dans cette partie la que vous devez décrire le plan de votre application, le fonctionnement des sous programmes et des modules, ce qu'ils retournent leur arguments ...

6.
Le mode d'emploi

Il ne s'agit pas seulement de lancer un programme, encore faut-il savoir s'en servir, n'hésitez pas à être bavard dans cette partie, c'est la plus importante pour les utilisateurs potentiels de votre application.

Il existe d'autres chapitres possibles a votre cahier des specs, comme un planning prévisionnel de développement ou une estimation des besoins ou des ajouts futurs. Un cahier des specs est comme le programme, il est la pour évoluer.

Tout cela semble bien compliqué pour pas grand chose, c'est aussi ce que je me suis dit lorsque j'ai écrit NesGet 1 et 2, à chaque fois, que je voulais rajouter une fonctionnalité au programme, je me retrouvai face à un mur et devais recomprendre mon code source en détail, sans parler de la phase de débogage. À la version 3, j'ai commencé par réaliser un cahier des specs, puis j'ai ré-écris le programme entièrement, je peux maintenant le faire évoluer parce que toute la phase de développement et de maintenance du programme a suivi une logique établie au départ.

Bien sur, cette logique évolue et le code change, mais tout est suivi, tracé et pensé avant action.


next up previous contents
Next: About this document ... Up: Introduction à PERL Previous: Perl et le système
Stephane TOUGARD
6/20/2001