Personne d'autre n'a encore mentionné l'épée à double tranchant, alors j'ajouterai mes 2 cents. Si vous avez plusieurs projets et qu'ils partagent tous du code réutilisable, conformément aux bonnes pratiques / principes de programmation (DRY par exemple), vous devez placer le code dans un emplacement global et le structurer de manière à ce qu'il puisse être partagé par tous. vos projets sans aucune modification. En d'autres termes, définissez les interfaces comme étant génériques et suffisamment communes pour convenir à tout le monde.
Il y a peu d'options pour ce faire: 1) Créez un projet de base dont d'autres dépendent. Ce projet peut créer une distribution binaire que d'autres projets consomment. 2) Tirez un modèle open-source au sein de votre organisation. Le code commun doit être sa propre branche de code et les autres projets doivent intégrer le code de la même manière que vous prendriez le code source de n'importe quel OSS en ligne.
Voici maintenant où l'épée entre en jeu ...
Placer du code dans un lieu commun dont dépendent d'autres projets / personnes peut devenir assez coûteux. Disons que vous avez un morceau de code et que 4 autres projets en dépendent. Un de vos clients qui utilise le projet A trouve un bogue et vous devez apporter une correction. Vous précipitez le correctif et ce client est heureux. Mais vous venez de modifier du code dont dépendent 3 autres projets. Avez-vous retesté tous ces éléments pour vous assurer qu'aucune condition de bord n'a été introduite?
Le code commun doit également être conçu avec beaucoup plus de soin et les interfaces des modules doivent être bien mieux conçues car ce code doit accueillir non pas un mais 4 clients et chacun d'entre eux pourrait simplement utiliser ce code avec une différence si légère.
Si vos projets sont sur des cycles de publication différents, vous devez être encore plus prudent dans la gestion du code commun. Vous ne pouvez pas simplement apporter des modifications dans le code commun car le projet B a besoin de nouvelles fonctionnalités, si vous êtes à 3 jours de couper l'image finale pour le projet C.
Je ne dis pas qu'une bibliothèque commune n'est pas la bonne solution. Je suis un fervent partisan de DRY et j'ai déjà créé et pris en charge du code commun et je continue de le faire. Je voulais juste dire que le simple fait de rendre le code commun aura ses propres dépenses.
Si vous êtes le seul à réutiliser ce code, ce n'est pas aussi mauvais. Si vous avez une équipe d'ingénieurs et qu'ils commencent à utiliser le code commun, les dépenses augmentent encore plus. Si d'autres sont impliqués, attendez-vous à ce que le placement de code dans une bibliothèque commune prenne 3 fois plus de temps qu'il le faudrait pour arriver à un point où vous pensez qu'il est "complet". Vous devrez a) rendre la bibliothèque plus robuste pour vous protéger contre toutes sortes de conditions de périphérie et d'utilisation non valide, b) fournir de la documentation pour que d'autres puissent utiliser la bibliothèque et c) aider d'autres personnes à déboguer lorsqu'elles utilisent la bibliothèque d'une manière que vous n'ont pas anticipé et votre documentation ne couvre pas leur cas d'utilisation spécifique.
Quelques suggestions que je peux vous proposer:
- Avoir du code commun couvert par des tests unitaires automatisés peut aller très loin et vous donner une idée que lorsque vous apportez une modification, vous ne vous contentez pas de casser un autre projet.
- Je ne placerais que des fonctionnalités très stables dans du code commun. Si vous avez écrit un cours l'année dernière pour faire de la gestion des minuteurs et que vous ne l'avez pas changé en 9 mois et que vous avez maintenant 3 autres projets qui ont besoin de minuteurs, alors c'est sûr que c'est un bon candidat. Mais si vous venez d'écrire quelque chose la semaine dernière, eh bien ... vous n'avez pas beaucoup d'options (et je déteste le copier / coller du code probablement plus que le gars suivant) mais je réfléchirais à deux fois avant de le rendre commun.
- Si un morceau de code est trivial mais que vous l'avez utilisé à plusieurs endroits, il vaut peut-être mieux mordre la balle, laisser DRY tranquille et laisser plusieurs copies vivre.
- Parfois, il est avantageux de ne pas simplement mettre du code commun dans un emplacement commun et que tout le monde y fasse référence. Mais considérez plutôt le code commun comme son propre libérable avec les versions, les dates de sortie et tout. De cette façon, le projet C peut dire: «J'utilise la bibliothèque commune v1.3» et si le projet D a besoin de nouvelles fonctionnalités, vous laissez la v1.3 seule, libérez la v1.4 et le projet C n'est pas affecté. Gardez à l'esprit qu'il est BEAUCOUP BEAUCOUP plus cher de traiter le code commun comme son propre produit plutôt que de simplement le faire archiver dans un emplacement commun.