Comment votre organisation gère-t-elle les composants communs?

Question

Un composant commun est une bibliothèque ou un autre élément de code créé et géré par un groupe et utilisé par plusieurs groupes.

Certains de nos problèmes sont les suivants:

• Les utilisateurs ne signalent aucun problème avec les composants.
• Les utilisateurs créent des solutions de contournement aux composants en fonction de leurs besoins.
• Ils rompent la compatibilité avec la version de coffre simplement pour respecter leurs délais.
• Les utilisateurs finissent par coder leurs propres solutions (moins robustes) car ils pensent que c'est mieux.

Comment votre organisation gère-t-elle les composants communs?

Idées que j'ai:

• Traitez le composant comme un projet open source et demandez aux équipes de soumettre des correctifs.
• Interdit totalement les modifications personnalisées du code.
• ...

Answer 1

Ce que vous avez ici peut être un problème de facteurs humains plutôt que technique. En fait, il peut s’agir essentiellement d’un problème d’apprentissage (associé au syndrome typique qui n’est pas inventé ici).

Ayant travaillé dans de grandes entreprises, je me rends compte qu’il est difficile pour une nouvelle personne de comprendre toutes les ressources (bibliothèques de codes partagés) à sa disposition, encore moins comment et quand les utiliser correctement.

Lorsque vous avez un nouvel employé, reçoit-il / elle une formation formelle dans votre bibliothèque de composants communs?

Ensuite, il y a le problème de ce que les gens sont récompensés. Au moment de la révision, les responsables récompensent-ils les personnes qui utilisent les composants communs, les améliorent et soumettent les améliorations à la bibliothèque? Ou bien les gestionnaires se soucient-ils simplement de leurs propres projets.

Quant à votre groupe qui gère la bibliothèque commune, quelle forme ou quelle reconnaissance donnent-ils aux personnes qui prennent le temps de suggérer ou de soumettre des améliorations? Sont-ils écrits dans le bulletin d'information de l'entreprise? Obtenir un bonus en argent? Obtenir leur photo sur le tableau bulliten?

N'oubliez pas qu'il est très peu probable que des personnes fassent quelque chose pour une entreprise pour laquelle elles ne reçoivent aucune reconnaissance ou récompense.

Answer 2

Nous essayons de passer à davantage de systèmes basés sur les services. Ainsi, si nous créons une fonctionnalité particulière pour un projet, elle peut être utilisée à partir d'un autre projet via un service Web. De cette façon, il n'y a qu'une seule instance du code.

Naturellement, cela fonctionne mieux pour certains types de composants (un exemple: nous avons récemment créé un service de création de PDF) que pour d'autres (probablement trop cher pour un utilitaire de manipulation de chaîne).

Answer 3

Le seul composant réussi que j'ai vu ici est redistribué dans une version compilée (* .dll). Les utilisateurs signalent les bogues et demandent les fonctionnalités directement avec l'équipe propriétaire et les implémentent eux-mêmes. Il existe une API permettant d'écrire vos propres plugins pour les éléments les plus susceptibles de changer, afin que les utilisateurs puissent étendre les fonctionnalités dans de nombreux cas.

Il y a toujours un compromis à

• convaincre les gens d'utiliser votre composant
• conservez un niveau de qualité raisonnable en même temps

Vous ne savez pas quelle est la meilleure chose à faire dans votre cas, mais en général, essayez de mettre en œuvre la logique de base vous-même, de garder le composant configurable / extensible afin que les utilisateurs n'aient pas besoin de changer le noyau à tout moment et d'offrir un bon support. . Pour une raison quelconque, certains développeurs ont toujours tendance à réinventer la roue, aussi stupide soit-elle, donc je ne m'en ferais pas trop.

Answer 4

Un bon moyen consiste à instituer des révisions périodiques du code. Au cours de ces opérations, si vous trouvez une roue réinventée, vous pouvez utiliser cette opportunité pour informer les développeurs sur l'utilisation de composants communs ou sur les raisons pour lesquelles ils ont ressenti le besoin de les réinventer et d'allier leur raisonnement au code d'origine. Ainsi, les exigences de chacun sont définies et les composants améliorés pour tous.

Answer 5

Traitez-les de la même manière que les bibliothèques tierces. Je ne laisserais même pas les autres équipes voir la source. Cela risquerait donc de faire perdre beaucoup de temps à la critique et à la persécution.

Answer 6

Quelle est la taille de l'organisation? J'ai très bien vu le problème dans une petite organisation (quelques dizaines de programmeurs au total) où une ou deux personnes sont connues pour être propriétaires de chaque composant et qui répondent aux demandes de fonctionnalités.

Il est plus facile de se rendre au bureau de quelqu'un (ou de le poster), d'expliquer ce dont vous avez besoin et d'obtenir l'un des éléments suivants:

• la manière prévue de faire ce que vous voulez,
• accord pour ajouter la fonctionnalité requise (ou demander à un séide de le faire),
• autorisation d'implémenter la fonctionnalité requise dans le composant commun,

Puisqu'il suffit de se lancer dans l'écriture de solutions de contournement, le démarrage d'un fork ou l'écriture d'un nouveau composant équivalent. Si vos programmeurs sont intelligents, ils feront ce qu’ils pensent être le plus facile. Le truc, c'est de s'assurer que c'est la bonne chose.

À part des choses très simples comme des listes chaînées, il n’ya pas eu beaucoup de réinvention de la roue. Il existait très rarement des fourchettes privées pour des produits particuliers, le plus souvent pour réduire la taille du code en découpant des éléments. Mais la manière habituelle de le faire était de modifier le composant d'origine pour avoir plus d'options de compilation.