Re: [Dolibarr-dev] Futur de Dolibarr

[Yannick Warnier]

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)

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

- incertitude face au résultat (tant qu'on n'a pas essayé on ne sait pas
si ça nous donnera satisfaction)

- avantages théoriques dont le résultat pratique reste à prouver

- obligation d'utiliser un outil particulier, alors que chacun a des
préférences établies

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