Leçons apprises dans les tranchées

Code commun dans la nature

Alors que Git est idéal pour collaborer sur un seul référentiel, le partage de code entre plusieurs projets peut

Pour commencer, nous avons examiné notre propre base de code pour savoir combien de fois nous avons dupliqué notre propre intégration à notre service utilisateur. Le résultat incroyable était pas moins de 86 instances. Après le choc initial, nous avons commencé à penser que cela devait aussi se produire ailleurs

Nous avons demandé à des amis travaillant dans différentes organisations de différentes tailles d'exécuter une simple fonction de copier-coller sur leur base de code, en recherchant des doublons de code de plus de 100 lignes. Le résultat nous a emporté: en moyenne, plus de 30% de leur base de code a été dupliquée.

Enfin, nous avons décidé d'étudier en profondeur les projets Open Source sur GitHub, en vérifiant à la fois les duplications et les réimplantations simples. isString fonctionne dans les 10 000 projets JavaScript GitHub les plus populaires

Étonnamment, nous avons trouvé cette fonction a été implémentée de plus de 100 façons et dupliquée plus de 1000 fois dans seulement 10.000 dépôts. Des études ultérieures affirment que plus de 50% du code sur GitHub est en réalité dupliqué . Nous avons réalisé que nous n'étions pas les seuls à faire face à ce problème.

Avant de construire Bit nous avons cherché un outil qui nous aiderait à transformer les composants plus petits que nos applications sont construits à partir de blocs de construction qui pourraient être partagés entre nos projets et synchronisés à travers notre base de code. Nous voulions aussi les organiser et les rendre découvrables pour notre équipe. Voici un bref résumé de ce que nous avons appris.

Un arsenal de micro-paquets avec NPM

Au début, nous envisagions de publier tous nos composants d'interface utilisateur, fonctions utilitaires et modules plus petits sous forme de paquets vers NPM. Cela semblait être la solution évidente pour la modularité des blocs de construction de nos logiciels. Cependant, nous avons rapidement appris que cette solution était très lourde.

Essayer de publier quelques fichiers de notre projet sur NPM nous a forcés à diviser notre dépôt et à en créer de nouveaux juste pour partager ce code. En traitant avec des centaines de composants, cela signifiait devoir maintenir et faire des changements à travers des centaines de dépôts .

Nous devrions également refactoriser notre base de code, enlevant les paquets nouvellement créés de leurs dépôts originaux. les paquets dans les nouveaux dépôts et ainsi de suite.

Même alors, nous avions maintenant un moyen simple d'organiser ces paquets et de les rendre facilement détectables à toute notre équipe. Un autre problème majeur était le couplage entre les paquets et les propriétaires de leurs référentiels d'origine, ce qui rendait presque impossible pour d'autres personnes de faire rapidement des mises à jour des paquets tout en travaillant sur leurs propres projets.

nous à gérer. Donc, nous avons rapidement décidé de chercher un meilleur moyen de partager notre code.

Lerna Monorepos

La prochaine option que nous avons trouvée a été d'utiliser Lerna pour refactoriser notre base de code en un quelques référentiels multi-paquets, souvent appelés "monorepos".

L'avantage de cette solution était qu'elle nous permettrait de maintenir et de publier tous nos paquets à partir d'un seul référentiel. Cependant, cette option présentait également un ensemble d'inconvénients, en particulier lorsque vous utilisiez des composants plus petits.

Choisir cette option signifiait que nous devions conserver plusieurs paquets avec plusieurs fichiers package.json plusieurs environnements de construction et de test et un arbre de dépendances complexe à gérer entre eux. La mise à jour de ces paquets doit également passer par le dépôt principal, ce qui rend difficile la modification de ces paquets à partir d'autres projets lorsque vous travaillez avec quelques monorépos séparés.

Par exemple, prenez l'interface utilisateur Material-UI React bibliothèque. Même s'il utilise Lerna pour publier cinq packages différents à partir du même référentiel, vous devez toujours installer la bibliothèque entière pour utiliser chacun de ses composants. Des changements devraient encore être effectués dans ce projet, et la découverte de ces composants ne s'est pas améliorée.

Monorepos peut être utile dans certains cas (comme tester ou construire un projet dans son ensemble) et peut certainement fonctionner pour quelques équipes. Cependant, la refactorisation de votre base de code entière juste pour partager le code commun entre les projets tout en ayant à faire face aux problèmes mentionnés ci-dessus nous a fait abandonner cette option.

Bibliothèques partagées

Cette option a également été rapidement abandonnée. À bien des égards, cela ressemble à l'utilisation d'un CD-ROM au lieu d'une liste de lecture iTunes. Premièrement, cela n'a aucun sens de forcer une bibliothèque entière de composants React et une bibliothèque entière d'utilité et ainsi de suite sur chacun de nos projets.

Deuxièmement, chaque projet l'utilisant serait fortement couplé au développement de cette bibliothèque, le rendant impossible d'ajuster ses composants pour chaque projet. Cela devient plus pénible quand on partage un code Node.js commun entre nos microservices, qui seraient maintenant couplés à la bibliothèque.

Troisièmement, la découvrabilité dans la bibliothèque est forcément mauvaise et impliquerait beaucoup de travail avec sa documentation et son utilisation.

Comme il est peu logique de coupler et de ralentir notre développement, nous essayons de minimiser l'utilisation de ces bibliothèques autant que possible . Même les bibliothèques de JavaScript populaires telles que Lodash travaillent dur pour rendre leurs plus petits composants disponibles indépendamment via NPM.

Git Submodules

Enfin, nous avons tourné le dos et avons cherché à travailler avec Git sous-modules .

Vous y êtes. Vous songez à utiliser un sous-module Git. NE PAS. Ne fais pas ça.

– Jeremy Kahn (@jeremyckahn) 16 décembre 2012

Git vous permet de faire d'un dépôt un sous-répertoire d'un autre dépôt, en créant un seul arbre de travail pour l'ensemble du projet, afin qu'un référentiel puisse utiliser le code d'un autre référentiel.

Comme beaucoup d'autres équipes, cette solution n'a pas duré pour nous. Premièrement, les sous-modules ne fonctionnent que sur la branche maîtresse, ce qui pose des problèmes pour un développement rapide. Deuxièmement, les sous-modules augmentent le couplage entre les projets, ce qui rend difficile le travail sur les affectations inter-référentiels. Enfin, un dépôt de sous-module est inconscient de sa propre imbrication et de l'existence de dépôts dépendants.

Après avoir essayé ces différentes solutions, nous avons réalisé que cela ne devrait pas être si compliqué. Il devrait vraiment y avoir une façon plus simple d'organiser, de partager et de développer des composants du code à partir de différents projets. Nous avons donc décidé de le construire et nous l'avons appelé Bit

Building Bit

Notre vision d'une solution était simple: transformer nos composants et nos modules en blocs de construction facilement isolables projet, organisé dans le nuage et utilisé dans tout projet.

Lors de sa construction, nous avons établi quelques lignes directrices pour ce dont nous avions besoin du projet.

• Rendre transparent et isoler les composants de code de tout projet, sans avoir à créer de nouveaux dépôts ou manuellement configurez les environnements de construction et de test et les dépendances pour chaque composant.
• Activez le développement bidirectionnel, de sorte que chaque composant puisse être modifié et mis à jour à partir de n'importe quel projet, tandis que les modifications seraient synchronisées dans notre base de code. organiser et partager nos composants, tout en les rendant visibles pour toute notre équipe avec des informations visuelles utiles.

Après un travail acharné et une recherche approfondie, nous avons publié en 2017 la première version de Bit à GitHub. Comment ça marche

Le workflow de Bit est composé de trois étapes simples:

1. Le premier consiste simplement à dire à Bit quels composants de code vous souhaitez partager de votre projet, et il commencera immédiatement à suivre leur Dans tous les projets, vous les partagez.
2. Vous pouvez ensuite marquer une version pour ces composants afin que Bit définisse et verrouille automatiquement leur dépendance pour les dépendances de fichiers et de packages, et crée un environnement isolé pour chaque composant à construire et test isolé
3. Enfin, vous pouvez partager les composants sur le cloud (ou votre propre serveur distant), où ils seront organisés, seront rendus détectables et pourront être installés avec NPM ou Yarn comme n'importe quel autre paquet. [19659053] Vous n'avez pas besoin de créer de nouveaux dépôts, de fractionner votre base de code ou de refactoriser une seule ligne de code.

   Maintenant vient la partie vraiment cool. Vous pouvez également utiliser Bit pour importer les composants dans d'autres projets pour un développement ultérieur. Parce que Bit suit vos composants entre les projets, vous pouvez les développer simultanément à partir de différents référentiels et synchroniser les changements dans votre base de code.

   Ce workflow rapide et distribué signifie que vous ne serez pas lié par des problèmes de propriété.

   Exemple: Bit avec les composants de l'interface utilisateur Réagir

   

   Pour cet exemple, choisissons un cas d'utilisation commun: synchroniser les composants de l'interface utilisateur de Réaction entre les applications. Bien que conçu pour être réutilisable, l'obtention d'une telle réutilisabilité peut être difficile .

   Prenons un exemple React app sur GitHub. Il contient huit composants React UI réutilisables et un composant de style global. Comme vous pouvez le voir, Bit a été ajouté au référentiel (voir les fichiers bit.json et .bitmap ) pour suivre ces composants – mais aucune ligne de code n'a été modifiée dans le dépôt. De là, les composants ont été partagés à portée correspondant sur le hub web libre de Bit.

   Comme vous pouvez le voir, chacun des composants est maintenant disponible pour tout développeur pour installer avec NPM ou Yarn ou d'importer dans leurs propres projets pour le développement ultérieur.

   Tous les composants sont organisés et peuvent être partagés avec votre équipe et recherchés via un moteur de recherche. Ils sont présentés avec des résultats de rendu, de construction et de test visuels (vous pouvez utiliser des environnements de construction et de test préfabriqués et créer les vôtres), et viennent avec des documents analysés automatiquement afin que vous puissiez prendre une décision éclairée.

   Une fois que vous avez changé de projet, vous pouvez mettre à jour la version du composant dans la portée (qui fonctionne comme source de vérité à distance) et synchroniser les changements entre différents dépôts.

   Un petit tutoriel pour React est disponible pour le projet exemple.

   Conclusion

   Le partage de code entre projets est essentiel pour créer des logiciels plus rapidement, tout en simplifiant la maintenance et le développement de votre base de code dans le temps. Comme de plus en plus de nos applications sont construites en utilisant des composants réutilisables comme les composants React et Vue UI, les modules Node.js, les fonctions simples, les API GraphQL et bien d'autres, les transformer en blocs de construction devient plus gratifiant.

   de séparer des référentiels, de refactoriser des projets et de modifier des composants de différents projets peut rendre difficile la collaboration et le partage efficaces de votre code. Ce sont les leçons tirées de notre propre voyage vers le partage de code simple et efficace ce qui simplifie le partage, la découverte et la collaboration en tant qu'équipe tout en construisant avec nos briques LEGO communes.

   projet source, alors n'hésitez pas à sauter dans suggérer des commentaires ou demander quelque chose . Rappelez-vous simplement que, au bout du compte, le partage de code concerne toujours les gens et le développement d'une culture collaborative où les gens jouent ensemble pour construire de grandes choses.

   (fr, re, al, yk, il )