В домашних библиотеках многократного использования - повторно использовать как dll или как проекты?

Есть несколько вещей, чтобы рассмотреть здесь.

• Сколько дополнительного времени эти библиотеки добавляют к компиляции, и вас это волнует?
• Как часто вам нужно исправлять в них ошибки?

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

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

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

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

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

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

Но это останавливается на уровне приложения. Любой проект, который не будет всегда развертываться с основными библиотеками, не использует совместное решение, он просто ссылается на скомпилированную DLL. Это заставляет меня быть дисциплинированным в отношении изменений в библиотеке и не начинать ее настройку для поддержки какой-то конкретной функции пользовательского интерфейса.

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

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

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

Я работал над проектом, где разработчики автоматически публиковали новые версии своих dll в локальной сети. Решение, над которым мы работали, просто ссылалось на DLL из этого конкретного места. Проблема заключалась в том, что мы никогда не знали, для какой версии библиотеки мы компилируем, и более одного раза, после тестирования, мы выпускали версию нашего приложения, которая ломалась, потому что внезапно была выпущена новая версия этой библиотеки (которую мы не знали). не тест).

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

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