22-08-2019, 04:01 PM
ma vision (et c'est ce qu'on fait de note côté):
seul common peut changer common.
c'est donc :
y a un triple intérêt:
- ça t'oblige a vérifier sur ta dernière version de common que tout est ok
- ça te pousse à mettre à jour ton projet client quand il en a besoin
- ça évite que des équipes "projet" interviennent sur le "common" (normalement des équipes plus expertes)
bon évidemment dans le cas d'un type tout seul le troisième point n'est pas valable
pas vraiment
le processus que nous avons si un projet a besoin d'un changement/ajout
je développe le changement dans le projet, je le teste dans le projet, je le valide dans le projet (mais dans des fichiers spécifiques du projet, via surcharge ou création de classe, ou que sais-je, ça dépend du langage)
le jour où on décide que ce changement mérite une industrialisation (donc mise au pot commun), on récupère le code et on l'intègre dans common. On le teste dans common, on le valide dans common (avec potentiellement des améliorations du fait qu'il devient générique)
Puis on modifie le projet (et éventuellement d'autres) en supprimant les fichiers spécifiques pour intégrer la fonctionnalité proposée par common puis test et validation.
L'intérêt de ce processus est de focaliser le projet sur le projet. La fonctionnalité est "common-able" mais elle est d'abord fait pour le projet (planning, tout ça) et elle doit marcher pour le projet, sans réfléchir trop (réfléchir est dans notre adn cependant) sur les cas non utiles au projet
et quand on bascule sur common, ce n'est pas que du copier coller, c'est de la prise de recul, de l'enrichissement, de l'optimisation mais dans un temps plus long, sans la pression du planning du projet
seul common peut changer common.
c'est donc :
Citation :L'alternative plus standard qui existe serait de faire les modifs du Common dans le Common, de le "release", puis d'indiquer dans les projets le n° de version du Common à utiliser.
y a un triple intérêt:
- ça t'oblige a vérifier sur ta dernière version de common que tout est ok
- ça te pousse à mettre à jour ton projet client quand il en a besoin
- ça évite que des équipes "projet" interviennent sur le "common" (normalement des équipes plus expertes)
bon évidemment dans le cas d'un type tout seul le troisième point n'est pas valable
Citation :Mais cela m'oblige à release le Common avant de pouvoir tester, dans ECLERD, si tout marche... Je trouve ça lourd?! Et quand bien même il existerait un moyen, cela m'obligerait à modifier le Common dans mon projet Common, à "fake release" ces modifs, à les mettre à jour côté ECLERD, et enfin seulement, vérifier si c'est tout OK... C'est très leeent (et chiant) je trouve.
pas vraiment
le processus que nous avons si un projet a besoin d'un changement/ajout
je développe le changement dans le projet, je le teste dans le projet, je le valide dans le projet (mais dans des fichiers spécifiques du projet, via surcharge ou création de classe, ou que sais-je, ça dépend du langage)
le jour où on décide que ce changement mérite une industrialisation (donc mise au pot commun), on récupère le code et on l'intègre dans common. On le teste dans common, on le valide dans common (avec potentiellement des améliorations du fait qu'il devient générique)
Puis on modifie le projet (et éventuellement d'autres) en supprimant les fichiers spécifiques pour intégrer la fonctionnalité proposée par common puis test et validation.
L'intérêt de ce processus est de focaliser le projet sur le projet. La fonctionnalité est "common-able" mais elle est d'abord fait pour le projet (planning, tout ça) et elle doit marcher pour le projet, sans réfléchir trop (réfléchir est dans notre adn cependant) sur les cas non utiles au projet
et quand on bascule sur common, ce n'est pas que du copier coller, c'est de la prise de recul, de l'enrichissement, de l'optimisation mais dans un temps plus long, sans la pression du planning du projet