Fiches / Articles

Cadre Fonctionnel

Organisation d'un développement

Cadre Technique

Ant/CVS/JavaDoc

Identifiant 

ORG_01

Référent technique 


Version 

1.0

Auteur 

Alexandre Brillant

Date 

04/01

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 :

I. Organisation des répertoires

Une organisation possible :

Bin

Scripts diverses (exécution…)

Build

Classes construites

Src

Sources respectant l'arborescence associée aux packages

Doc

Documentation technique et javadoc

Distrib

Distribution selon la phase du projet

Lib

Librairies pour la compilation et l'exécution

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

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 :

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).