Fusion de bibliothèques de base

Question

Il ya environ un an, notre société a déployé un progiciel relativement important écrit principalement par deux développeurs expérimentés. Pour faciliter la démonstration, je l'appellerai "projet A". Depuis, nous travaillons sur un nouveau progiciel, le "projet B" et dans son arbre est une branche du projet A.

Le projet B fait référence au projet A, mais maintenant que nous approchons de la fin du projet B, nous avons aussi besoin de référencer B depuis A. Donc, après avoir fusionné les branches de A et avant d'aller vivre avec B, nous aimerions fusionner les bibliothèques de base entre les deux projets.

Quelles sont les expériences que vous avez eues avec ce type de situation? Quelles sont les meilleures pratiques et les leçons apprises sur ce projet? Comment pouvons-nous fusionner les bibliothèques de base avec un impact minimal sur le reste du code source du projet A?

EDIT: Quel est votre avis sur la faisabilité du maintien projet A espaces de noms de, mais localiser le code dans la bibliothèque de base de projet B (qui deviendra finalement la bibliothèque de base de l'entreprise)? A partir de là, la nouvelle référence juste bibliothèque de base de l'entreprise dans les projets existants ...

EDIT 2: Merci pour les réponses. Peut-être qu'une clarification un peu plus technique est nécessaire. Ces deux projets sont très étroitement liés, mais chacun a son propre projet .NET Class Library pour une bibliothèque principale. Au-delà, chaque bibliothèque est référencée par d'autres projets .NET différents; Plus de ma question est où le code source devrait vivre - je ne crois pas qu'ils devraient rester deux projets .NET séparés, mais un seul projet contient les deux, en gardant les espaces de noms existants initialement . Comme nous continuons à développer, nous allons refactoriser, en combinant les espaces de noms, en éliminant les doublons, etc. Il y a sans aucun doute des fonctionnalités contenues dans les bibliothèques existantes qui seront utiles dans les projets à venir et il y a aussi un besoin émergent de partager bibliothèques "core".

Answer 1

est votre problème avec la possibilité de références cycliques entre B et A?

Ou plus sur les espaces de noms conflictuels entre A et B.A?

Si A et B.A se trouvent dans le même espace de noms (A) dans le même projet, je pense que vous pourriez rencontrer de sérieux conflits.

Une possibilité est d'ajouter un préfixe d'espace de noms aux deux bibliothèques, et en fonction de ce que vous voulez vous pouvez importer celui-là?

-à-dire

A devient V1.A et BA devient V2.A (sous le projet B)

Alors si vous voulez vous V1 importer simplement l'espace de noms V1, V2 si vous voulez importer le V2 namespace et les références devraient s'aligner je pense?Vous rencontrerez toujours des problèmes car si vous jouez avec l'espace de noms pour A, vous casserez tout code existant qui le référence déjà comme A et non V1.A. Honnêtement, je pense que dans un projet, vos assemblées et vos espaces de noms doivent être uniques. Donc, si vous avez deux versions d'assemblées avec le même espace de noms ... l'une d'entre elles doit partir.

Answer 2

Je pense que cela dépend fortement de la langue, de l'environnement et du type de bibliothèques (liées dynamiquement/statiquement). Quels problèmes attendez-vous?

• identificateurs entrant en collision
• fonctionnalité double
• modifications au processus de construction
• de tests d'intégration/unité