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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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