L'organisation d'un développement doit séparer la partie création de la partie mise en exploitation. L'objectif étant de limiter les interventions dans la seconde partie afin de permettre une réactivité importante (fin de phase…)

La partie création doit cependant respecter certaines règles importantes portant sur :

• L'organisation des répertoires

• La conception des sources

• La synchronisation des sources

• Les tests et déploiements

I. Organisation des répertoires

Une organisation possible :

Un script build.xml à la racine permet d'automatiser les actions de :

• Compilation,

• Test unitaire et de déploiement,

• Construction de la documentation à partir de javadoc (outil de génération de la documentation à partir d'un format de commentaires dans les fichiers sources),

• Synchronisation des ressources par CVS (Concurrent Version System)

• Suppression des classes produites

II. Construction des sources

Un fichier source doit suivre une logique rigoureuse, il est un composant du système et sa fonction doit être clairement délimitée.

L'emploi du format javadoc permet :

• Des sources commentées de manière homogène

• La diffusion immédiate d'une documentation de développement notamment dans le cas de branches multiples

• Le contrôle de l'impacte des "facilités" de commentaires dans le code et la pertinence des informations

• La possibilité d'étendre par des doclets la documentation de base pour l'adapter aux méthodes de développement en cours (voir les fiches de développement).

L'emploi de javadoc n'implique pas que toutes les méthodes soient commentées. Seules les méthodes non triviales de par leur dénomination doivent être commentées.

Outre l'emploi de javadoc, il est important de minimiser le "bruit" dans les fichiers sources. Une règle d'indentation homogène peut être adoptée. Les méthodes publiques les plus importantes doivent être mises en évidence et placées de préférence en tête de classes. A contrario, les variables privées peuvent être placées en fin de classe car elles n'ont en générales pas d'intérêt pour l'exploitation (méthodes publiques …).

Des règles de nommage peuvent être employées pour séparer les rôles principaux des classes. Les interfaces sont les briques essentielles du code, afin de limiter la connaissance des implémentations, aucune convention de nommage ne doit distinguer une interface de classe. Cependant, les classes réalisant une interface pourront être suffixées ou préfixées par les termes "impl", "basic", … . Les classes abstraites n'ayant pas d'utilité directe devront être préfixées par le terme Abstract.

III. Synchronisation des sources

La synchronisation par CVS nécessite toujours la démarche opérationnelle suivante :

1°) Exécuter un "update" (synchronisation des sources locales avec le serveur) pour synchroniser les sources locales avec les sources du serveur

2°) Compiler les sources

3°) Test et exécution

4°) "Commiter" (synchronisation des sources du serveur avec les sources locales) les changements pour mettre à jour le serveur

Il ne faut jamais "commiter" des sources non testées. Cela peut avoir un impact important sur le processus de développement. Cependant, un retour sur une version antérieure est toujours possible.

Lorsque des branches de développement très hétérogènes existent, il est plus utile d'utiliser plusieurs entrées sur CVS que d'avoir une arborescence comprenant tous les sources de développement (effet spaghetti). Les différentes parties d'exécutent selon leurs relations grâce à des jar mis dans le répertoire lib (effet cannelloni). Ces jars seront eux-mêmes synchroniser par CVS.

Des fichiers complémentaires ou "log de développement" pourront être utilisés. Ils contiendront une trace des derniers changements opérés (date, auteur et changements).

Des tests unitaires seront nécessaires pour les fonctions complexes. L'assemblage avec des parties inexistantes (en phase de développement) pourra se faire par l'utilisation d'implémentation de simulation. La plupart du temps, des implémentations de type "adapter" c'est–à-dire n'implémentant aucun traitement seront suffisants.

Lorsque des parties seront soumis à une sollicitation importante, des mini-simulateurs pourront être construits (boucler sur un noyau coûteux). Ils estimeront le coût moyen d'un traitement.

Pour que le déploiement se fasse avec le minimum d'impact avec l'existant, plusieurs jars pourront être construits représentant différents niveaux de stabilité dans le code (le formework, les implémentations).