Meilleures pratiques pour partager de minuscules extraits de code entre projets
J'essaie toujours de suivre strictement le principe SEC ; chaque fois que j'ai répété du code par paresse, il mord plus tard quand j'ai besoin de maintenir ce code à 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 mutuellement. La méthode peut être liée à la mise en réseau/chaînes/MVVM, etc. et est une méthode généralement utile non spécifique au projet dans lequel elle se trouve à l'origine.
La manière standard de réutiliser ce code serait de créer un projet indépendant pour le code réutilisable et de référencer ce projet lorsque vous en avez besoin. Le problème est que nous nous retrouvons dans l'un des deux scénarios moins qu'idéaux:
- Nous nous retrouvons avec des dizaines/centaines de petits projets - chacun pour héberger les petites classes/méthodes que nous avions besoin de réutiliser. Vaut-il la peine de créer un tout nouveau
.DLLjuste pour un tout petit peu de code? - Nous nous retrouvons avec un seul projet contenant une collection croissante de méthodes et de classes indépendantes. Cette approche est ce que faisait une entreprise pour laquelle je travaillais; ils avaient un projet nommé
base.commonqui avait des dossiers pour des choses comme je l'ai mentionné ci-dessus: mise en réseau, manipulation de chaînes, MVVM etc. C'était incroyablement pratique, mais le référencer faisait glisser inutilement avec lui tout le code non pertinent dont vous n'aviez pas besoin.
Ma question est donc:
Comment une équipe logicielle peut-elle utiliser au mieux la réutilisation de petits morceaux de code entre les projets?
Je suis particulièrement intéressé si quelqu'un a travaillé dans une entreprise qui a des politiques dans ce domaine, ou qui a rencontré personnellement ce dilemme.
note: Mon utilisation des mots "Projet", "Solution" et "Référence" provient d'un arrière-plan dans le développement .NET dans Visual Studio. Mais je suis sûr que ce problème est indépendant de la langue et de la plate-forme.
S'il s'agit vraiment de 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 framework:
Framework.Data- Utilitaires pour travailler avec les requêtes de base de données.Framework.ESB- Méthodes standard pour interagir avec notre bus de services d'entrepriseFramework.Logging- Système de journalisation unifiéFramework.Services- Utilitaires pour interagir avec les services WebFramework.Strings- Utilitaires pour la manipulation avancée de chaînes/recherche de chaînes floues, etc.- ...
Au total, il existe une dizaine de bibliothèques. Vous pouvez vraiment distribuer le code comme bon vous semble, vous n'avez donc pas à vous retrouver avec des centaines ou à tout vider dans un assemblage géant. Je trouve que cette approche convient car seuls certains de nos projets auront besoin de Framework.Data et seuls quelques-uns auront besoin de Framework.Strings, afin que les consommateurs ne puissent sélectionner que les parties du cadre pertinentes pour leur projet particulier.
Si ce ne sont vraiment que des extraits de code, et non des méthodes/classes réelles qui peuvent être facilement réutilisées, vous pouvez simplement les distribuer sous forme d'extraits de code dans le IDE (par exemple Visual Studio Code Extraits ). Les équipes avec lesquelles j'ai travaillé dans le passé avaient une bibliothèque d'extraits commune qui permettait à tout le monde de suivre plus facilement nos pratiques de codage standard avec du code interne.
Je ne suis pas d'accord avec la réponse acceptée pour de nombreuses 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 non inventé ici (NIH) ) - a péché bien plus grand que violer Ne vous répétez pas (SEC) .
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 une petite quantité, appliquez le - Règle de trois ) de duplication est plus facile à comprendre qu'une base de code spaghetti.
L'approche de nombreuses bibliothèques à usage général donne un mauvais exemple. Cela conduit à une granularité fine de l'assemblage et un trop grand nombre d'assemblages est mauvais. J'ai récemment réduit une maison de 24 bibliothèques à 6 bibliothèques. Il a amélioré le temps de compilation de plusieurs minutes à environ 20 secondes. Visual studio est également plus lent à charger et moins réactif avec plus d'assemblys. Le fait d'avoir trop de bibliothèques entraîne également une confusion quant à l'emplacement du code; préférez des règles moins nombreuses et plus simples.
Pourquoi le contenu du .Net Framework n'est-il pas assez bon? Le cadre est assez grand; plusieurs fois, j'ai vu du code qui réimplémente des choses qui existent déjà là-bas. Assurez-vous vraiment que vos frameworks comblent les lacunes du framework .Net et n'existent pas seulement pour des raisons esthétiques (par exemple "Je n'aime pas le framework .Net ici" ou peut-être certains optimisation prématurée )
L'introduction d'une autre couche dans votre architecture a un coût de complexité considérable. Pourquoi la couche existe-t-elle? J'ai vu une fausse réutilisation, j'entends par là que le code est construit sur un framework interne. Il aurait été beaucoup plus efficace de l'implémenter directement au-dessus des bibliothèques standard.
L'utilisation de technologies standardisées (comme le framework .Net et les bibliothèques tierces/open source populaires) présente des avantages qui dépassent souvent les gains technologiques comparatifs de sa construction vous-même. Il est plus facile de trouver des talents qui connaissent ces technologies et vos développeurs existants investiront davantage dans leur apprentissage.
Mes recommandations:
- Ne partagez pas ce code.
- Créez une nouvelle bibliothèque si elle a un objectif cohérent, n'utilisez pas le modèle de conception de boule de boue .
- Réutilisez les bibliothèques tierces existantes dans la mesure du possible.
- Préférez moins d'assemblys, avec des règles plus simples quant à l'emplacement du code.
Pour les petits morceaux de code - disons une seule classe sans dépendances - nous avons tendance à simplement copier et coller le code dans les projets. Cela ressemble à une violation de DRY, et je dois admettre que cela peut parfois arriver. Mais à long terme, cela a été bien mieux que d'avoir une sorte de projet commun commun à plusieurs têtes pour plusieurs raisons.
Tout d'abord, il est plus simple d'avoir le code à portée de main, en particulier lors de la construction et du débogage.
Deuxièmement, vous voudrez toujours apporter quelques modifications au code commun de ce projet. Si vous avez une copie locale de la source, vous pouvez simplement créer le Tweak et l'appeler un jour. S'il y a une bibliothèque partagée, vous pouvez modifier cette bibliothèque et vous assurer de ne pas casser toutes les autres applications ou de créer un cauchemar de version.
Donc, si ce n'est pas assez costaud pour son propre espace de noms, nous avons tendance à le pousser dans les bits 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 assembly du GAC même si vous n'en utilisez qu'une seule classe. "Faire glisser du code non pertinent" n'est pas un problème comme vous pourriez le penser. Dans ce cas, il est essentiel de conserver au moins les méthodes et les classes associées organisées proprement dans différents espaces de noms. De plus, de bonnes pratiques de conception d'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 est un bon complément à un projet commun: autoriser leur duplication dans différentes solutions. Traitez-les comme les meilleures pratiques: documentez-les et communiquez-les à l'équipe.
Je n'ai jamais travaillé que dans des environnements "d'entreprise" où ce genre de chose a été un problème et à chaque fois c'est la deuxième option qui a été adoptée. Pour la plupart, cela a bien fonctionné car il n'y a pas eu de contrainte sur l'empreinte de l'application.
Cependant, après avoir passé la semaine dernière avec une start-up qui gère son propre serveur Nuget, je suis enclin à suggérer cela comme une alternative viable. Bien sûr, les problèmes que j'attends de voir se poseront autour de la capacité de découverte.
Si les projets sont suffisamment granulaires et que les espaces de noms sont raisonnables, je peux voir que cela devient une approche populaire par endroits.
J'ai récemment pensé à cela et ce qui m'est venu à l'esprit était une grande bibliothèque de méthodes courantes 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 quelles pièces sont incluses un peu comme le projet BusyBox . Avec cette approche, vous pouvez avoir un référentiel 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 assez utile pour enregistrer des extraits de code https://Gist.github.com/
Il stocke vos extraits de code en tant que référentiels git que vous pouvez garder privés ou utiliser pour partager des extraits de code avec d'autres personnes.
Selon 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 d'une manière ou d'une autre, et chaque solution que vous trouverez (si vous la mettez en œuvre) coûtera de l'argent. (Cela peut vous protéger davantage, mais que vous ne pourrez pas mesurer facilement). Vous devrez vérifier si cela vaut le prix. Gardez également à l'esprit que les solutions réutilisables ont tendance à devenir abstraites et conviennent souvent à de nombreuses situations, mais sans être optimales.
Dans tous les cas, si vous voulez le faire pour le code produit par plus d'une personne, vous aurez d'abord besoin de sensibilisation de tout le monde et de coopération. Cela inclut les développeurs et les gestionnaires.
Ensuite, vous devrez vous assurer que vous connaissez la portée dans laquelle vous souhaitez procéder. Équipe? Projet? Département? Compagnie? Selon la réponse, le type de code que vous mettrez dans de telles solutions variera, tout comme la granularité avec laquelle vous personnalisez les DLL. Une fois que vous avez décidé de cela, quelqu'un (de préférence avec un certain enthousiasme pour l'idée - vous?) Devrait s'asseoir et commencer à mettre une certaine structure dans cela.
La création de telles DLL ne sera cependant pas suffisante pour faire l'affaire. Afin de les rendre utiles, vous devrez en faire la publicité (auprès des utilisateurs et des contributeurs) et les maintenir comme tout autre logiciel, ce qui signifie généralement que vous devez en confier la responsabilité à quelqu'un pendant longtemps. Vous aurez également besoin d'une documentation fiable, qui nécessitera également une maintenance. Avec un peu de chance et de coopération, vous pouvez vous retrouver avec quelques bonnes pratiques, mais cela peut aussi facilement évoluer en un projet qui lui est propre, en fonction de la taille et du nombre d'équipes impliquées. Et pour cela, vous aurez toujours besoin d'un support de gestion.
j'ai rencontré beaucoup de problèmes, et ma solution préférée est de publier le code dans un référentiel Web github/pubic. cela résout beaucoup de problèmes -
- accès facile et facile à partager. cvs/svn/enterprise-repos signifie extraire le projet dans plusieurs espaces de travail IDE, et parfois devoir changer d'espace de travail ou d'ordinateurs juste pour faire référence à un petit extrait de code.
- en supposant que ces extraits de code ne sont pas des éléments de code propriétaires/classifiés et sont des variations des connaissances accessibles au public, les publier sur un référentiel public comme github signifie que d'autres le regarderont, et pourraient même contribuer.
- publier quelque chose dans le domaine public sous votre nom a la pression supplémentaire de la réputation. vous devrez vérifier et mettre à jour les choses, car cela reflète vos capacités en tant que programmeur.
- mises à jour. la chose à propos de la maintenance des extraits de code dans un référentiel est que si un extrait n'a pas été utilisé depuis longtemps, il peut devenir périmé (contenir des apis/libs obsolètes). exemple - Java extrait de code pour lire un fichier. vous avez peut-être trouvé la meilleure façon de le faire en 2009, mais en 2014 une nouvelle api de fichier sort qui change tout. votre extrait? encore bloqué en 2009. dans un dépôt public, les choses seront mises à jour, soit par vous (parce que puce 3), vos coéquipiers, ou un membre de la population générale des programmeurs, et dans le processus, vous pourriez même obtenir des suggestions pour réparer quelque chose que vous pourrait avoir fait du mal pendant longtemps.
Une chose que je recommanderais, peu importe où vous conservez vos extraits, toujours google stuff avant de l'utiliser. les choses changent tout le temps. les extraits enregistrés permettent de gagner du temps, mais aussi de faire preuve de complaisance.
Mon entreprise 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 demande http avec une interface définie. Comme il est 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 fonctionne qu'en millisecondes sur le même réseau local), mais il présente de très bons avantages.
Nous avons un projet séparé "utilitaires" où 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 "ajouter comme lien".
Cela signifie qu'aucune dépendance d'exécution n'est 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 diciplin sur ce qu'est un utilitaire. Exiger une couverture de test élevée a bien fonctionné pour nous et les tests sont également une bonne documentation d'utilisation. La découverte est toujours un problème non résolu pour nous.
Une complexité du projet utilitaire est de décider du niveau de visibilité sur les articles. En règle générale, les méthodes doivent être internes et les structures de données publiques.
J'ai récemment proposé ce service: Snip2Code ( http://www.snip2code.com ).
C'est une façon intéressante de partager uniquement vos extraits (pas entièrement des bibliothèques) avec votre équipe. Cela brise le point habituel de créer des bibliothèques communes qui devraient être référencées dans d'autres projets, et à mon avis, c'est une vision précieuse.
De plus, il existe de nombreux scénarios où l'utilisation d'une bibliothèque commune ne s'applique tout simplement pas: considérons par exemple certains modèles de conception comme Singleton, Strategy ou Observer. Vous pouvez créer des bibliothèques pour prendre en charge de tels modèles, mais il n'y a toujours pas de couverture à 100%.
Le vrai besoin est d'avoir un outil pour partager les pratiques communes au sein de l'équipe. J'ai essayé d'utiliser les gists 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 j'étais - avec mes co-fondateurs - dans votre même état d'esprit il y a quelque temps: c'est pourquoi nous avons décidé de lancer ce projet !!)