Почему команда разработчиков настаивает на том, что использование одного решения для нескольких проектов в Visual Studio «увеличивает сложность взаимозависимости»?

26

Я помогаю управлять внешней командой, которая начинает разрабатывать новые версии некоторых существующих продуктов. Исторически сложилось так, что эта команда всегда использовала модель одного проекта в одном решении для примерно 30 модулей в Visual Studio, которые объединяются для создания развертываемой сборки.

Это отрицательно сказывается на надежности и качестве сборки, поскольку они не всегда отправляют нам самый последний исходный код. Мы пытаемся заставить их объединить весь ссылочный код в единое решение, но мы получаем некоторое сопротивление - в частности, они продолжают говорить об увеличении взаимозависимости между модулями (читай «проекты» в Visual Studio), если все помещено в один файл решения. Ни один код в отдельных решениях не используется в других местах.

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

Рассматриваемая команда также выполняет исправление ошибок и разработку новых функций для существующего продукта, опыт которого был, мягко говоря, чреват и страдает от одной и той же проблемы разделения на несколько решений. Нам было отказано в доступе к их исходному контролю ( TFS ), и подход, который мы применяем для унификации кодовой базы, состоит в том, чтобы попытаться и, по крайней мере, уменьшить количество пропущенных обновлений и больше, чем случайные регрессии (да, исправляются исправленные ошибки. - введен в продукт), сказав: «отправьте нам ZIP-файл всей папки решения, чтобы мы могли распаковать его, открыть в Visual Studio и нажатьF5 для тестирования ". С точки зрения общей структуры и качества, код довольно скудный и его трудно поддерживать. Именно поэтому я намереваюсь выстроить рабочие процессы на самом раннем этапе цикла разработки, насколько это возможно.

Я что-то упускаю? Есть ли когда-нибудь веская причина держать весь этот код отдельно? За мои деньги это должно быть настолько веской причиной, что это станет общеизвестным, но я более чем готов признать, что я не знаю всего.

DrMistry
источник
5
Если команда внешняя, трудно будет что-то изменить. Вместо того, чтобы сосредоточиться на проблеме, вы пытаетесь выдвинуть свою идею. Проблема в том, что «они не всегда посылают нам обновленный код», если они решают эту проблему так, как они предпочитают. Разве они не могут предоставить вам доступ к системе контроля версий?
RMalke
9
Это звучит как чепуха. Проекты будут не более и не менее зависимы друг от друга, будь то в одном или тридцати решениях. Причина хранения кода в отдельных решениях заключается в том, что результирующая библиотека используется несколькими отдельными развертываемыми сборками. Это не похоже на случай для вас.
Дэвид Арно
3
Похоже, у вас много нетехнических проблем, которые лучше всего решаются с помощью изменений в вашем контракте и технических заданиях.
Росс Паттерсон
9
Создание одного решения не обязательно означает, что они должны отказаться от отдельных решений, поскольку проект может существовать в нескольких решениях.
Эрик Эйдт
6
Я не уверен, почему вы задаетесь вопросом о технических решениях чего-то, что по сути является проблемой людей. Увольнять этих людей и нанимать людей, которые выше среднего уровня компетентности. Это означает, что вы будете платить больше, но это определенно стоит в ИТ с точки зрения снижения совокупной стоимости владения. Чем дольше вы держитесь, тем больше вы будете страдать.
Брэд Томас

Ответы:

54

Вам не нужно рассказывать им, как структурировать свои проекты. Вместо этого сделайте жестким требованием, что вы можете собрать систему из исходного кода, запустив один единственный скрипт, не получая никаких ошибок. Если эти сценарии работают с Visual Studio или Msbuild или какими-либо другими инструментами, и если они вызываются один раз, то 50 или 100 раз не должны иметь значения.

Таким образом, вы получаете такой же «тест на полноту» кода, как и при объединении всего в одно решение. Конечно, этот сценарий не сообщает вам, действительно ли команда проверила последнюю версию из своего исходного кода, но наличие всего кода в одном решении также не проверяет это.

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

Тем не менее я бы предложил добавить скрипт сборки. Это имеет преимущества, даже когда существует только один файл решения. Например, он позволяет запускать сборку VS с предпочтительной конфигурацией, позволяет копировать окончательные файлы для развертывания (и ничего более) в папку «развертывания» и может запускать некоторые другие инструменты и шаги для завершения сборки. Смотрите также F5 это не процесс сборки! и тест Джоэл .

Док Браун
источник
Да, я согласен, что F5 не является процессом сборки, но мы хотим протестировать их код в команде разработчиков перед тем, как перейти к нашему процессу QA для сквозного тестирования, из-за регрессий и сбоев обновления. Как я уже сказал, у нас нет доступа к их TFS, поэтому мы должны импортировать их изменения в нашу собственную кодовую базу, а затем зарегистрировать их в TFS. В настоящее время этот процесс настолько плох, что запуск автоматической сборки при регистрации - пустая трата времени! У нас есть автоматическая сборка на остальной части нашего продукта, и он действительно работает очень хорошо для нас.
DrMistry
Просто хотел добавить, что материал "The Joel Test" превосходен, и я бы посоветовал хорошо выглядеть. Большое спасибо!
DrMistry
3

Это будет зависеть от того, насколько скомпилированные сборки используются повторно. Если нет повторного использования сборок, то нет никакой реальной причины отделять «модули» отдельно. На самом деле, по моему опыту, это больше препятствие.

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

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

KeithN
источник
Ни один из разделенных проектов вообще не используется нигде, это разочаровывает. Они все используются в этом одном продукте, и больше нигде!
DrMistry
1

Каждая софтверная компания, в которой я когда-либо работал, имела основную команду разработчиков, которая обеспечивала головной отдел, охватывающий основополагающие сценарии использования продуктов компании.

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

Вероятно, у вашей компании просто нет ресурсов, чтобы немедленно «объединить весь ссылочный код в единое решение». Предположение, что они делают это, не понимая своих бюджетных ограничений, (как минимум) может помешать ему стать основным инженером.

Так что сформулируйте свое грандиозное видение в несколько разрушительных запросов на притяжение к ядру и приготовьтесь защищаться в обзоре!

Доминик Черизано
источник
0

В утверждении «Использование единого решения для нескольких проектов лежит сложность взаимозависимости».

Единственное решение облегчает ссылки на проект из другого проекта (т.е. повторное использование кода проекта, известного как «введение сложности взаимозависимости»):

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

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

Каспер ван ден Берг
источник