Объединение основных библиотек - PullRequest
2 голосов
/ 20 мая 2009

Около года назад наша компания выпустила относительно большой программный пакет, написанный в основном двумя старшими разработчиками. Для простоты демонстрации я назову это «проект А». С тех пор мы работаем над новым программным пакетом "проект B", и в его дереве находится ветвь проекта A.

Проект B имеет ссылку на проект A, но теперь, когда мы приближаемся к завершению проекта B, нам также нужно сослаться на B из A. Таким образом, после объединения ветвей A и перед тем, как начать жить с B, мы хотел бы объединить основные библиотеки между двумя проектами.

Какой опыт вы испытали в подобной ситуации? Каковы некоторые лучшие практики и уроки, извлеченные из этого проекта? Как лучше всего объединить основные библиотеки с минимальным воздействием на остальную часть исходного кода в проекте A?

EDIT: Каково ваше мнение о целесообразности сохранения пространств имен проекта А, но при размещении кода в основной библиотеке проекта В (которая в конечном итоге станет основной библиотекой компании)? Оттуда, просто укажите новую библиотеку ядра компании в устаревших проектах ...

РЕДАКТИРОВАТЬ 2: Спасибо за ответы. Может быть, немного больше технических разъяснений в порядке. Оба эти проекта очень тесно связаны, но у каждого есть свой собственный проект .NET Class Library для основной библиотеки. Кроме того, на каждую библиотеку ссылаются другие различные проекты .NET; внутренние и внешние веб-приложения, приложения Forms и т. д. Больше меня интересует вопрос, где должен жить исходный код - я не верю, что они должны оставаться двумя отдельными проектами .NET, но один проект содержит оба, сохраняя изначально существующие пространства имен , По мере продолжения разработки мы будем проводить рефакторинг, объединяя пространства имен, удаляя дублирующиеся функции и т. Д. Нет сомнений в том, что функциональность, содержащаяся в обеих существующих библиотеках, будет полезна в будущих проектах, а также возникает потребность в совместном использовании между обоими существующими «основные» библиотеки.

Ответы [ 2 ]

1 голос
/ 21 мая 2009

Ваша проблема с возможностью циклических ссылок между B и A?

Или больше о конфликтующих пространствах имен между A и B.A?

Если и A, и B.A находятся в EXACT одном и том же пространстве имен (A) в одном и том же проекте, я думаю, вы можете столкнуться с серьезными конфликтами.

Одной из возможностей является добавление префикса пространства имен к обеим библиотекам, и в зависимости от того, что вы хотите, вы можете импортировать эту?

т.е.

A становится V1.A и B.A становится V2.A (под проектом B)

Итак, если вы хотите V1, вы просто импортируете пространство имен V1, если вы хотите V2, вы импортируете пространство имен V2, и ссылки должны выстроиться в линию, я думаю?

Вы все равно столкнетесь с некоторыми проблемами, потому что, если вы возитесь с пространством имен для A, вы нарушите любой унаследованный код, который уже ссылается на него как A, а не V1.A.

Честно говоря, я думаю, что в проекте ваши сборки и пространства имен просто должны быть уникальными. Так что если у вас есть две версии сборок с одним и тем же пространством имен ... одна из них должна уйти.

1 голос
/ 21 мая 2009

Метинкс это сильно зависит от языка, среды и типа библиотек (динамически / статически связанных). Какие проблемы вы ожидаете?

  • идентификаторы столкновения
  • дублирующая функциональность
  • изменения в процессе сборки
  • интеграция / модульное тестирование
...