VS.NET: судьи проекта по сравнению с судьями блока
Существуют некоторые дебаты здесь, по которым лучше для ссылки на нашу общую кодовую базу из других проектов: проектом или блоком. Я выступаю за ссылку на проект, тем более, что мы автоматизировали модульные тесты, которые доказывают, что общий код делает то, что это должно.
Мысль от другого лагеря состоит в том, чтобы заблокировать вниз те проекты и только выпустить блоки один раз в месяц или что-то. Тогда вызовите все проекты сослаться на блоки. Они думают, что это защитит их от развертывания непротестированного кода. Они "слишком заняты", чтобы записать автоматизированные модульные тесты и настроить их проекты для непрерывной интеграции, и я не имею никакого влияния на это, поэтому не фокусируйтесь на этом аспекте.
Вот причины, о которых я могу думать, почему ссылки проекта являются лучшим решением. Я ищу другие мнения также.
ПРОФЕССИОНАЛЫ:
- Ссылка на проекты гарантирует, что Вы работаете с последним кодом. Вы не должны ожидать ни на чем.
- Сокращение дублирования. Не имея последнего кода, существует больший шанс изобретения велосипед.
- Если разработчик будет нуждаться в чем-то и не сможет добавить его к блоку, где это принадлежит, это будет создано в любом месте, которое будет работать, создавая много несоответствий и кодировать дублирование.
- Разработка легче, потому что можно легко видеть/отлаживать то, что происходит в коде, на который ссылаются.
- Наш общий материал не изменяет это часто, но когда он делает, это обычно - что-то полезное. Почему добавляют дополнительную нагрузку управления версиями обслуживания и блока.
НЕДОСТАТКИ:
- Мог возможно занять больше времени для загрузки.
- Может взять немного дольше для добавления проектов к новому решению, тогда добавляющему ссылки на сборки.
2 ответа
Что ж, если вы используете какой-либо тип управления версиями, вы можете удовлетворить оба лагеря. Использование ветвления или маркировки (в зависимости от системы управления версиями).
Обычно, если у вас есть команда, которая контролирует ваш общий код, они могут ветвить / маркировать стабильный выпуск. Тогда ваши проекты будут использовать стабильную версию. Это защищает вас от развертывания нестабильного кода для других ваших проектов, а также дает вам возможность тестировать, отлаживать и просматривать весь исходный код.
Всякий раз, когда ваша группа общих элементов управления создает новую стабильную сборку, вы можете обновить ссылки на источники, чтобы получить данные из новой ветки.
Другой положительной стороной этого сценария является то, что у вас может быть исправление для общего кода, чтобы не мешать текущим усилиям по разработке. Конечно, это добавляет дополнительную нагрузку на руководство по обновлению общего кода более чем в одном месте, где это необходимо.
"Они платят, так что просто делайте то, что вам говорят, и не спорите" разумно, но приводит к тому, что кто-то хочет бездумной работы, как: "Чтобы не спорить, вы должны сделать все мои мысли. Ты в порядке с этим? Посмотрите, какой ответ это получит. Это нагнетает вещи в каком-то смысле, но иногда плохая игра «What if» должна быть полностью сыграна.
Вероятно, есть какая-то середина, где можно сказать: «Это то, чего мы хотим сейчас», и это то, что делается, а затем предлагаются улучшения. Изменение желания является частью процесса, как единственный способ выяснить, что вы не знаете, как правило, трудный путь.
Контраргумент заключается в том, что команда должна иметь чувство гордости за свою работу, и если то, что доставляется, будет считаться дерьмом снова и снова, в какой-то момент это выжжет большинство людей. Вы не против иметь высокий оборот? Некоторые места в порядке с выжиганием людей, а другие не так много. Как бы вы хотели бегать кругами или на большом хомячьем колесе день-два? Разве это не звучит как веселье?;)
У вас есть разумная основа для беспокойства, но ключ к тому, чтобы иметь некоторую гибкость, что вещи изменятся так, что в то время как первый результат может работать, как требуется, это больше не действует, и поэтому что-то еще должно быть сделано вместо этого. Мне напоминают, что бывший руководитель команды говорил нам: "90% вашего кода, вероятно, будет выброшено. Это как раз то, как это работает, прими это ". Как бы печально это ни звучало с точки зрения большой работы с небольшими хорошими результатами, это кажется довольно верным большую часть времени.
Один небольшой пункт добавить об этой гордости является то, что книга Дейла Карнеги «Как завоевать друзей и повлиять на людей» , в качестве одного из своих принципов «Будь лидером: как изменить людей, не обижаясь или не вызывая обиды:»
Дайте им прекрасную репутацию
В книге есть несколько историй, иллюстрирующих это.
-121--3579374-Я большой поклонник JGroups, но я недавно обнаружил лещина и, вероятно, даст ему попробовать. Это может быть то, что ты ищешь.
-121--2929555-Вот несколько достоинств вы упустили
- Обновление в реальном времени: такие функции, как intellisense, будут автоматически обновляться между ссылками на проекты при изменении API
- Определение GoTo: Если у вас есть ссылка на сборку, определение GoTo приведет вас к фактическому определению кода. Ссылка на сборку приведет к созданию подписи метаданных.
- Найти все ссылки: обработает весь код в ссылках проекта для использования ссылки. Для ссылки на сборку вы увидите только использования в метаданных
- Быстрый поиск (только 2010): Аналогично, чтобы найти все ссылки, просто лучше работает в P2P ссылке
В ответ на ваши недостатки
- Да: загрузка проекта, как правило, медленнее, чем загрузка ссылки.С разумным количеством проектов, хотя эта разница во времени не является значительной и не должна повлиять на вашу повседневную программу развития
- Да: Добавление проекта к решению, как правило, медленнее, чем добавление ссылки. Разница, правда, в секундах и является единовременной стоимостью. Я считаю ошибкой рассматривать это как часть критериев.