Discussion :

[LEK]

Bonjour,
ma société se relance pur la troisième fois dans la création d'un framework UI d'entreprise. Celui-ci couvre des composants côtés serveurs (api rest/hateoas+gestion authent.) et côté client on a du bootstrap + une bibliothèque de composants js du commerce que l'on wrappe dans des widget types pour former des écrans type : liste d'élément, écran de détail...
Si on se remet en question c'est que le temps de création d'une spa nous semble toujours élevé, réutiliser des composants entre équipes différentes est difficile, on se copie les uns les autres pour mettre en place une fonctionnalité comme cela avait été fait par ailleurs...
C'est sur ce framework que l'on se base pour créé une suite d'applications qui s'interfacent toutes dans le même portail web...
En bref j'aimerais savoir si dans vos boîtes aussi vous aviez la même approche? Comment assurez vous l'homogénéité de vos développements?

Merci pour vos retours.

[Marco46]

En bref j'aimerais savoir si dans vos boîtes aussi vous aviez la même approche? Comment assurez vous l'homogénéité de vos développements?

Oui j'ai déjà vu cette approche dans des grands comptes mais cela nécessite de bien faire les choses. Mal faire est pire que de ne rien faire. Cela peut créer des problèmes du type "je peux pas finir ma feature bidule parce que la team toto n'a pas publié la nouvelle version de la lib machin qui contient le composant truc nécessaire à la feature bidule". Et là c'est juste l'enfer, tu prends des effets tunnels de plusieurs mois dans la tête et des réunions à rallonge totalement inutiles.

L'organisation doit avoir l'habitude de gérer une collaboration fluide entre services et c'est vraiment pas donné à tout le monde. Une culture de l'opensource très présente dans les personnels techniques aide grandement au succès de la collaboration. Cela nécessite des outils de type GitLab / GitHub qui soient largement ouverts entre services, possibilité de contribuer dans la code base d'un service depuis un autre sans passer par une voie hiérarchique de réunions débiles entre chefs qui ne comprennent rien. Bref, si la structure hiérarchique de l'organisation est trop en mode "command and control" c'est compliqué voire infaisable, et c'est pourtant là que se situe le noeud du problème avant d'être un problème technique pur.

Autre point crucial, il faut aussi avoir un outil de publication des livrables, typiquement un registre privé (par ex avec Artifactory) afin de permettre aux équipes chargées d'écrire les dépendances de les mettre à dispo des autres équipes facilement. Cette gestion de dépendance ne doit pas être manuelle il faut passer par npm et un registre privé et suivre scrupuleusement semver.

Donc en résumé, il faut comprendre que lorsqu'on commence à créer des dépendances pour factoriser du code entre équipes, on ne crée pas seulement une dépendance technique, on crée aussi une dépendance organisationnelle et hiérarchique et ça ça peut faire très mal dans des organisations qui ne sont pas préparées à collaborer correctement. Donc danger ! Même si c'est effectivement la bonne approche

[LEK]

Merci Marco46, pour ta réponse. Cela sent le vécu et effectivement me rappelle plusieurs tranches de vies ;-)

Mais je pense que j'ai mal posée ma question :
- ce que j'essaye de demander c'est comment les autres construisent leur IHM pour des applis de gestion (lob) en entreprise?
surtout lorsqu'il faut créer une suite de différentes applications qui devront avoior des aspects et comportement communs (en saisie, validation,navigation..)
- Est-ce que vous utiliser un framework JS (type react,angular,vue) plus quelques plugins jquery et un framework CSS puis vous créer la dessus des composants js/css partagés?
- Est-ce vous développer tout from scratch avec une lib de base type jquery ?
- Est-ce que pour ce tye d'applis il vaut mieux rester sur du html généré côté serveur ?

Voilà peut-être trop de questions mais je pense que j'ai plus clarifié mes questionnements?