Tout comme à la maison (d’après ma femme !), il est utile pour retrouver ces petits de faire un peu de rangement.
L’organisation du code source ne déroge pas à cette règle. Cela peut paraître simpliste, voir inutile de faire un papier sur ce sujet, mais l’expérience me prouve que ce sujet n’est pas toujours appliqué.
Le principe est simple :
- L’environnement de développement doit être identique à l’environnement de production.
J’entends par là que les sources, les fichiers de configuration, les scripts et tous autres artefacts qui servent à la mise en œuvre de l’application doivent être rangés dans des répertoires organisés de la même manière que ceux déployer pour exécution.
Ce principe de base d’organisation de la configuration logicielle simplifie le déploiement, les procédures d’installation en évitant les « pertes » de fichiers.
Autre avantage à cette organisation des sources et de limiter la divergence d’exécution entre la version lancée sous Eclipse et celle déployée. De permettre donc de traiter (identifier, voir reproduire) les bugs en environnement de dév, plutôt qu’en environnement d’intégration où il n’y a souvent pas de débugger.
Avec Eclipse, j’engage les développeurs à utiliser un projet par package fonctionnel mais aussi technique : 1 pour le client, 1 pour le serveur, 1 pour les tests, 1 pour les « commons ».
Cela garantie la séparation des couches et évite au développeur de tirer des classes serveurs directement dans le package client.
L’utilisation des Working Set Eclipse permet d’améliorer la vue lorsqu’il y a une multitude de projets.
Sans parler de standardisation (breeuuu…), l’organisation des sources pour le développement d’une appli web est souvent contrainte par l’organisation des conteneurs (webapps).
Répertoire WEB-INF, lib, js, conf, … Certains plugins Eclipse imposent même l’arborescence des sources.
Il est intéressant de s’inspirer de ces principes pour le développement d’application non web.
Nouvelle version disponible de Robotframework Eclipse Library, 0.10
