Пространства имен в сочетании с объяснением TFS / Source Control - PullRequest
Новая
       27

Пространства имен в сочетании с объяснением TFS / Source Control

0 голосов
/ 18 февраля 2010

Как компания, выпускающая ПО, мы постепенно сталкиваемся с вопросом «структурируй свой код». Мы в основном разрабатываем с использованием Visual Studio 2008 и 2010 RC. Языки c # и vb.net. У нас есть собственный Team Foundation Server и, конечно, мы используем Source Control. Когда мы начали разработку на основе .NET Framework, мы также начали использовать Пространства имен примитивным образом. Со временем, когда мы «стали более зрелыми», я имею в виду, что мы научились использовать пространства имен и структурировали код все больше и больше, но только в рамках решения. Теперь у нас есть около 100 различных проектов и решений в нашем Source Safe. Мы поняли, что многие из наших собственных классов закодированы очень избыточно, то есть функция Write2Log, GetExtensionFromFilename или аналогичная функция может быть найдена от одного до 20 раз во всех этих проектах и ​​решениях.

Итак, моя идея:

Создание единого вида корневой папки в Source Control и запуск собственной структуры пространства имен иерархии под этим корнем, назовем ее CompanyName. Класс Write2Log будет затем найден в CompanyName.System.Logging. Всякий раз, когда мы создаем новое решение или проект и нам нужна функция журнала, мы будем «пространством имен» этого решения и размещать его соответственно где-нибудь ниже корневой папки CompanyName. Чтобы получить функциональность регистрации, мы импортируем (добавляем) существующий проект в решение. Эти 20+ проектов / решений с классом write2log могут быть сохранены в одном месте.

На мои вопросы: - это хорошая идея, философия пространств имен и контроля версий? - Должна быть хорошая книга, объясняющая пространства имен в сочетании с Source Control, да? какие-либо советы / указания / советы? - как вы управляете 50+ проектами?

1 Ответ

1 голос
/ 18 февраля 2010

Вот как мы это делаем (мы также ISV, и мы используем TFS):

У нас есть внутренняя структура, которую используют все наши продукты. Инфраструктура включает в себя базовые классы для нашего уровня доступа к данным, такие службы, как ведение журнала, служебные функции, элементы управления пользовательским интерфейсом и т. Д.).

Итак, у нас есть командный проект для нашей среды: Framework \ v1.0 \ Main \ Framework

(обратите внимание на повторение "framework", выглядит странно, но это важно)

Затем у нас есть командный проект для каждого продукта, и мы разрабатываем фреймворк в командном проекте:

ProductName \ v1.0 \ Main \ ProductName

ProductName \ v1.0 \ Main \ Framework (ветвь от \ Framework \ v1.0 \ main \ Framework, мы делаем эту ветку доступной только для чтения)

любой код в "\ Main \ ProductName" может ссылаться на любой код в \ Main \ Framework

Далее, если нам нужно создать рабочие ветки нашего продукта, мы просто разветвляемся на "Main" следующим образом:

ProductName \ v1.0 \ WIP \ MyBranch \ (ответвление от Main, где MyBranch == Main)

Это дает нам 2 действительно интересных функции:

  1. Я могу создавать ветки, не путая мои ссылки, пока держу все под «Основным» вместе. Это потому, что VS будет использовать относительные пути к ссылкам, и до тех пор, пока я все вместе держу под заголовком Main (и я НЕ ссылаюсь ни на что "выше" main, относительные пути остаются нетронутыми.

  2. Если я обновлю «реальную» среду (в папке \ Framework \ v1.0)), я могу выбрать для каждого продукта, когда я хочу объединить эти обновления структуры в базу кода продукта.

(это действительно полезно, если вы используете разделяемые библиотеки, потому что он отделяет внутренние выпуски вашей общей платформы от внешних выпусков ваших продуктов). Если вы просто переходите в общие библиотеки, одна из проблем, с которой вы столкнетесь, - это «коллизии», когда изменение вашего общего кода требует внесения изменений в код вашего продукта, чтобы оставаться совместимым. Разветвив свой общий код, вы можете обновить свою платформу, не оказывая немедленного воздействия на все ваши продукты одновременно.

...