Yannick Warnier a écrit :
Les gros désavantages sont:
- inapplicabilité à un projet dont les développeurs sont distants et ne
peuvent se réunir régulièrement pour discuter de la structure du code à
venir (et donc inapplicabilité dans le cas d'une petite équipe de
développement éparpillée et travaillant sur des tranches horaires
différentes comme c'est le cas pour l'instant)
En ce qui me concerne, je remarque généralement le contraire sur les
gros projets Java. De plus, ceci avais l'avantage de permettre un
meilleur respect des règles. Car il y a toujours des développeurs
cochons qui codent au kilomètre.
Attention, ce sont seulement les signatures (bean) implémentant le PEAR
DB, générés ainsi que les états standard (listes, fiches) et les
templates (smarty) attenants. Les méthode métier restent à implémenter.
- temps d'apprentissage de l'outil non souhaité (je crois que nous avons
tous un autre projet qui prime sur Dolibarr dans nos vies, et que donc
Dolibarr est un produit qui passe au second rang en général, ou
uniquement temporairement au premier rang)
En contrepartie d'un gain énorme de temps lors de la phase de
développement
- incertitude face au résultat (tant qu'on n'a pas essayé on ne sait pas
si ça nous donnera satisfaction)
Je vais essayer et je donnerais un aperçu
- avantages théoriques dont le résultat pratique reste à prouver
Le plus gros avantage et d'améliorer la lisibilité de l'application à
très long terme.
- obligation d'utiliser un outil particulier, alors que chacun a des
préférences établiest
C'est vrai.
Ces arguments ne nient pas les avantages que tu énonces, mais rajoutent
une partie désavantages que tu n'as pas citée.
En gros, ce serait essayer d'appliquer une méthode de logiciel développé
par une équipe en entreprise à un logiciel développé par des
développeurs séparés géographiquement. L'expérience que j'en ai est une
démotivation des participants (sauf celui qui a initié le changement de
méthode). Je veux bien participer à un cas où ça marche, cela dit (pour
l'étendue de ma contribution, c'est probablement plus de travail pour
moi proportionnellement à mon travail pour Dolibarr).
L'un dans l'autre, je crois que le mieux dans ce genre de cas est de
développer d'abord un module avec le nouveau système pour voir un peu
comment ça se comporte, puis de décider d'aller plus loin ou non.
Yannick
Le mercredi 24 octobre 2007 à 15:00 +0200, Cyrille de Lambert a écrit :
Les gros avantages de ce type de méthode :
* Le code est généré suivant la norme qui a été définie par le
projet. C'est nous qui choisissons comment il doit-être (Le
plus orienté objet possible, intégration de smarty,etc)
* Le code généré est propre
* Il est possible de standardiser certains comportements
* Il est possible de modifier des templates générés car c'est
une génération incrémentale.
Cyrille
Rodolphe Quiedeville a écrit :
Cyrille de Lambert a écrit :
Que pensez-vous de ceci pour le futur de Dolibarr ?
http://www.acceleo.org/pages/module-uml2-vers-php/fr
Bonjour,
Pour moi cela sort un peu de l'esprit de départ du projet. Je n'aime
pas vraiment les générateurs de codes. Je préfère de loin avoir des
écrans précis avec les bonnes informations et avec une forme en
relation avec le contenu que les ecrans standardisés ou l'on
retrouve un code postal sur 50 caractère ;-)
A++
_______________________________________________
Dolibarr-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
|