Meilleures pratiques pour le partage de minuscules extraits de code entre projets

J'essaie toujours de suivre le principe DRY strictement au travail; chaque fois que je répète du code par paresse, il mord plus tard lorsque je dois le conserver à deux endroits.

Mais souvent, j'écris de petites méthodes (peut-être 10 à 15 lignes de code) qui doivent être réutilisées dans deux projets qui ne peuvent pas se référencer. Cette méthode peut être liée à la mise en réseau / aux chaînes / au MVVM, etc. Il s’agit d’une méthode généralement utile qui n’est pas spécifique au projet dans lequel elle est placée

La méthode standard pour réutiliser ce code consiste à créer un projet indépendant pour le code réutilisable et à référencer ce projet lorsque vous en avez besoin. Le problème, c’est que nous nous retrouvons dans l’un des deux scénarios suivants:

1. Nous nous retrouvons avec des dizaines / centaines de petits projets - chacun pour héberger les petites classes / méthodes que nous devions réutiliser. Vaut-il la peine de créer un tout nouveau .DLLpour juste un petit bout de code?
2. Nous nous retrouvons avec un seul projet contenant une collection croissante de méthodes et de classes sans rapport. Cette approche est celle d’une entreprise pour laquelle j’ai travaillé auparavant; ils avaient un projet nommé base.commonqui contenait des dossiers pour les choses que j'ai mentionnées ci-dessus: réseau, manipulation de chaîne, MVVM, etc. Il était incroyablement pratique, mais le référencer entraînait inutilement tout le code inutile dont vous n'aviez pas besoin.

Donc ma question est:

Comment une équipe de logiciels réagit-elle au mieux pour la réutilisation de petits morceaux de code entre projets?

Je m'intéresse particulièrement si quelqu'un a travaillé dans une entreprise qui a des politiques dans ce domaine ou qui a personnellement rencontré ce dilemme, comme moi.

Remarque: mon utilisation des mots "Projet", "Solution" et "Référence" provient d'un contexte de développement .NET dans Visual Studio. Mais je suis sûr que ce problème est indépendant de la langue et de la plateforme.

Si ce sont vraiment des méthodes / classes réutilisables, vous pouvez les écrire dans un petit nombre de bibliothèques 'Swiss Army Knife'. Nous le faisons assez souvent dans mon entreprise. nous les appelons bibliothèques de cadres:

• Framework.Data - Utilitaires pour travailler avec des requêtes de base de données.
• Framework.ESB - Méthodes standard d'interaction avec notre bus de service d'entreprise
• Framework.Logging - Système de journalisation unifié
• Framework.Services - Utilitaires pour interagir avec les services Web
• Framework.Strings - Utilitaires de manipulation avancée de chaîne / recherche de chaîne fuzzy, etc.
• ...

En tout, il y a environ une douzaine de bibliothèques. Vous pouvez vraiment distribuer le code comme bon vous semble, de sorte que vous n'ayez pas à vous retrouver avec des centaines de personnes ou à tout jeter dans un assemblage géant. Je trouve que cette approche convient, car seuls certains de nos projets en auront besoin Framework.Dataet quelques-uns n'en auront jamais besoin Framework.Strings, de sorte que les consommateurs ne peuvent sélectionner que les parties du cadre pertinentes pour leur projet.

S'ils ne sont que des extraits, et non des méthodes / classes pouvant être facilement réutilisées, vous pouvez simplement les distribuer sous forme d'extraits de code dans l'EDI (par exemple , Extraits de code Visual Studio ). Les équipes avec lesquelles j'ai travaillé par le passé disposaient d'une bibliothèque commune d'extraits de code facilitant le respect de nos pratiques de codage standard avec le code interne.

Je ne suis pas d'accord avec la réponse acceptée pour plusieurs raisons.

D'après mon expérience, quand je vois des bibliothèques "diverses" comme la réponse acceptée, elles sont une excuse pour réinventer la roue (ou ne sont pas inventées ici ), un péché bien plus grave que celui de violer Dont Repeat Yourself (DRY) .

Parfois, violer DRY peut être un compromis raisonnable, c'est mieux que d'introduire un couplage serré. La réutilisation est une préoccupation secondaire par rapport à une bonne conception orientée objet. Un peu (je veux dire un petit montant, appliquer la règle de trois ) de la duplication est plus facile à comprendre qu'une base de code spaghetti.

L'approche de nombreuses bibliothèques d'usage général donne le mauvais exemple. Cela conduit à une fine granularité d'assemblage et trop d'assemblages est mauvais. J'ai récemment réduit une maison de 24 bibliothèques à 6 bibliothèques. Le temps de compilation est passé de quelques minutes à environ 20 secondes. Visual Studio est également plus lent à charger et moins réactif avec plus d'assemblages. Avoir trop de bibliothèques mène également à la confusion quant à où le code devrait vivre; préférez moins de règles simples.

Pourquoi les éléments du .Net Framework ne sont-ils pas suffisants? Le cadre est assez grand; j'ai souvent vu du code réimplémenter des éléments existants. Assurez-vous vraiment que vos frameworks comblent des lacunes dans le framework .Net et n'existent pas uniquement pour des raisons esthétiques (par exemple, "je n'aime pas le framework .Net ici" ou peut-être une optimisation prématurée ).

L'introduction d'une autre couche dans votre architecture a un coût de complexité important. Pourquoi la couche existe-t-elle? J'ai vu de fausses réutilisations, je veux dire par là que le code est construit sur un framework interne. Il aurait été beaucoup plus efficace de l’appliquer directement au-dessus des bibliothèques standard.

L'utilisation de technologies normalisées (telles que le framework .Net et les bibliothèques populaires tierces / open source) présente des avantages qui contrebalancent souvent les avantages technologiques comparatifs de sa création par vous-même. Il est plus facile de trouver des talents connaissant ces technologies et vos développeurs existants investiront davantage dans leur apprentissage.

Mes recommandations:

• Ne pas partager ce code.
• Créez une nouvelle bibliothèque si elle a un objectif cohérent. N'utilisez pas le modèle de conception boule de boue .
• Réutilisez les bibliothèques tierces existantes si possible.
• Préférez moins d'assemblys, avec des règles plus simples quant à l'emplacement du code.

Pour de petits morceaux de code - disons une classe unique sans dépendances - nous avons tendance à simplement copier et coller le code dans des projets. Cela ressemble à une violation de DRY, et j'admets que cela peut être parfois. Mais à long terme, cela a été beaucoup mieux que d’avoir une sorte de projet commun massif à plusieurs têtes pour plusieurs raisons.

Premièrement, il est simplement plus simple d’avoir le code à portée de main, en particulier lors de la création et du débogage.

Deuxièmement, invariablement, vous voudrez apporter quelques modifications au code commun de ce projet. Si vous avez une copie locale de la source, vous pouvez simplement modifier le réglage et l'appeler un jour. S'il existe une bibliothèque partagée, vous pouvez peut-être modifier cette bibliothèque, puis vous assurer de ne pas détruire toutes les autres applications ou de créer un cauchemar de gestion des versions.

Donc, s'il n'est pas assez costaud pour son propre espace de noms, nous avons tendance à l'insérer dans les éléments appropriés du projet et à l'appeler un jour.

La deuxième solution que vous décrivez n'est pas si mauvaise. Dans .NET, vous référencez également un assemblage à partir du GAC même si vous n'en utilisez qu'une seule classe. "Traîner du code non pertinent" n'est pas un problème comme vous pourriez le penser. Dans ce cas, il est essentiel de garder au moins les méthodes et les classes liées bien organisées dans différents espaces de noms. De plus, les bonnes pratiques de conception des API doivent être appliquées pour éviter que cette solution ne devienne un gâchis.

S'il s'agit de très petits morceaux de code, je pense que l'approche suivante complète bien un projet commun: autorisez leur duplication dans différentes solutions. Traitez-les comme des meilleures pratiques: documentez-les et communiquez-les à l'équipe.

Je n'ai jamais travaillé que dans des environnements «d'entreprise» où ce genre de problème était un problème et chaque fois, c'était la deuxième option adoptée. La plupart du temps, tout a bien fonctionné, car l'encombrement des applications n'a pas été limité.

Cependant, après avoir passé la semaine dernière avec une start-up qui exécute son propre serveur Nuget, je suis enclin à suggérer cela comme une alternative viable. Bien entendu, les problèmes que je compte voir se poseront autour de la capacité de découverte.

Si les projets sont suffisamment détaillés et que les espaces de noms sont sensibles, je peux voir que cela devient une approche populaire par endroits.

J'ai récemment réfléchi à cette question et ce qui m'est apparu était une grande bibliothèque de méthodes communes, comme cela a été mentionné jusqu'à présent, mais avec une torsion. Le projet de bibliothèque vous permettrait de configurer au moment de la compilation les éléments inclus, comme le projet BusyBox . Avec cette approche, vous pouvez avoir un dépôt de bibliothèque de style évier de cuisine, mais ne saisir que les outils dont vous avez besoin lors de la compilation.

GitHub a un outil très utile pour enregistrer des extraits de code https://gist.github.com/

Il stocke vos extraits de code sous forme de référentiels git que vous pouvez garder confidentiels ou utiliser pour partager des extraits de code avec d'autres personnes.

En fonction de la taille de l'équipe / du projet / de l'entreprise, ce sera assez difficile à faire efficacement, à moins qu'il ne soit déjà intégré à votre environnement, et chaque solution que vous trouverez (si vous la mettez en œuvre) coûtera de l'argent. (Cela peut vous protéger davantage, mais vous ne pourrez pas mesurer facilement). Vous devrez vérifier si cela vaut le prix. N'oubliez pas non plus que les solutions réutilisables ont tendance à devenir abstraites et s'adaptent souvent à de nombreuses situations sans être optimales.

Dans tous les cas, si vous souhaitez utiliser ce code pour le code produit par plusieurs personnes, vous devez d’abord prendre conscience de l’intérêt de tous et de la coopération. Cela inclut les développeurs et les gestionnaires.

Ensuite, vous devez vous assurer de connaître la portée dans laquelle vous souhaitez le faire. Équipe? Projet? Département? Compagnie? En fonction de la réponse, le type de code que vous utiliserez dans ces solutions variera, de même que la granularité avec laquelle vous personnaliserez les dll. Une fois que vous avez décidé de le faire, quelqu'un (de préférence avec un certain enthousiasme pour l’idée - vous?) Devrait s’asseoir et commencer à mettre en place une structure.

La création de telles DLL ne suffira pas pour faire l'affaire. Afin de les rendre utiles, vous devez les publier (auprès des utilisateurs et des contributeurs) et les gérer comme tout autre logiciel, ce qui signifie généralement que vous devez leur confier la responsabilité à long terme. Vous aurez également besoin d'une documentation fiable, qui nécessitera également un entretien. Avec un peu de chance et de coopération, vous pourrez vous retrouver avec certaines meilleures pratiques, mais cela peut aussi facilement devenir un projet à part, en fonction de la taille et du nombre d’équipes impliquées. Et pour cela, vous aurez toujours besoin d'un support de gestion.

Je me suis souvent heurté à des problèmes, et ma solution préférée consiste à publier le code dans un référentiel Web github / pubic. cela résout beaucoup de problèmes -

1. accès facile et facile à partager. cvs / svn / enterprise-repos signifie que le projet est archivé dans plusieurs espaces de travail IDE et qu'il est parfois nécessaire de changer d'espace de travail ou d'ordinateur simplement pour faire référence à un petit extrait de code.
2. en supposant que ces extraits de code ne sont pas des éléments de code exclusifs / classifiés et constituent des variantes de la connaissance accessible au public, les afficher sur un dépôt public comme github signifie que d'autres personnes l'examineront et pourraient même y contribuer.
3. publier quelque chose dans le domaine public sous votre nom a la pression supplémentaire de la réputation. vous allez vérifier et mettre à jour les choses, car cela reflète vos capacités en tant que programmeur.
4. mises à jour. La chose à propos de la conservation des extraits de code dans un référentiel est que, si un extrait n'a pas été utilisé depuis longtemps, il pourrait devenir périmé (contenir des apis / libs obsolètes). exemple - extrait de code Java permettant de lire un fichier. vous avez peut-être trouvé le meilleur moyen de le faire en 2009, mais en 2014, une nouvelle api de fichier apparaît qui change tout. votre extrait? toujours bloqué en 2009. dans un rapport public, les choses seront mises à jour, soit par vous (parce que la puce 3), vos coéquipiers, ou un membre de la population des programmeurs généraux, et dans le processus, vous pourriez même recevoir des suggestions pour corriger quelque chose qui vous avez peut-être mal agi pendant longtemps.

Une chose que je recommanderais - peu importe où vous gardez vos extraits, recherchez toujours Google avant de l'utiliser. les choses changent tout le temps. Les extraits sauvegardés font gagner du temps, mais génèrent également de la complaisance .

Nous avons un projet séparé "utilitaires" dans lequel nous stockons toutes ces petites méthodes avec des tests.

Lorsqu'un projet a besoin d'un utilitaire, il ajoute simplement le fichier source avec la méthode requise avec "add as link".

Cela signifie qu'aucune dépendance d'exécution n'a été ajoutée (sauf si le fichier inclus en a besoin).

Le système a bien fonctionné mais, comme tous les autres, il a besoin de la précision sur ce qu’est un utilitaire. L'exigence d'une couverture de test élevée a bien fonctionné pour nous et les tests constituent également une bonne documentation d'utilisation. La découverte reste un problème non résolu pour nous.

Une complexité du projet de service public consiste à décider du niveau de visibilité des éléments. En règle générale, les méthodes doivent être internes et les structures de données publiques.

Ma société utilise des services Web intranet locaux. Nous avons quelques services Web configurés en tant que services Web internes communs, et lorsqu'un autre projet a besoin d'accéder à l'un des services, il envoie une requête http avec une interface définie. Comme il se trouve sur l'intranet, hébergé dans la même batterie de serveurs, ces demandes sont très rapides.

Évidemment, cela ne fonctionne qu'avec les applications Internet (et ne le fait qu'une fois par milliseconde sur le même réseau local), mais il présente de très bons avantages.

J'ai récemment eu ce service: Snip2Code ( http://www.snip2code.com ).

C'est un moyen intéressant de partager uniquement vos extraits (pas entièrement des bibliothèques) avec votre équipe. Créer une bibliothèque commune qui devrait être référencée dans d’autres projets est en rupture avec le point de vue habituel. À mon avis, cette vision est précieuse.

En outre, il existe de nombreux scénarios dans lesquels l'utilisation d'une bibliothèque commune ne s'applique tout simplement pas: considérons par exemple certains modèles de conception tels que Singleton, Strategy ou Observer. Vous pouvez créer des bibliothèques pour prendre en charge de tels modèles, mais il n’ya toujours pas de couverture à 100%.

Le vrai besoin est de disposer d'un outil pour partager les pratiques communes au sein de l'équipe. J'ai essayé d'utiliser les bases de Github, mais je suis coincé avec leur recherche (vraiment médiocre) et avec le fait que je ne peux pas les partager uniquement avec mon équipe et pas avec d'autres ...

(Avertissement: je suis l'un des fondateurs de Snip2Code et, avec mes co-fondateurs, j'étais dans votre état d'esprit il y a quelque temps: c'est pourquoi nous avons décidé de démarrer ce projet !!)