В доме допускающие повторное использование библиотеки - повторное использование как dll или как проекты?
У нас есть довольно мало повторно используемого кода на работе (хорошая вещь). Каждый раз, когда я создаю новый проект, которые используют их, я используюсь для включения их проектов как часть моего решения, и я задавался вопросом, должен ли я вместо этого снова использовать их как опубликованный dll's вместо этого. Причина (или оправдание) я включаю проект, то, что, если я нахожу ошибку в одном из них, я могу перейти и зафиксировать это тут же. Но это, кажется, берет мой фокус из проекта под рукой.
(Не уверенный, если бы это должно быть CW с тех пор, существует только два ответа, и я интересовался бы приобретением знаний о Ваших предпочтениях),
4 ответа
Здесь нужно учесть несколько моментов.
- Сколько дополнительного времени эти библиотеки добавляют к компиляции, и волнует ли это вас?
- Как часто вам нужно исправлять ошибки в них?
Я использую прекомпилированные библиотеки для любого кода, который не меняется месяцами. Если мне нужно менять какой-то код в пакете чаще, чем раз в месяц, то этот пакет не прекомпилируется.
Я предпочитаю прекомпиляцию для ускорения компиляции основной программы. Но я всегда включаю отладочные символы в прекомпиляцию, чтобы в случае ошибки я мог просмотреть прекомпилированную сборку так же легко, как и остальную.
Это действительно зависит от того, входите ли вы в команду, отвечающую за них, или нет, если вы в команде, добавляйте их в свой источник и исправляйте их по мере необходимости. Если вы не входите в эту команду, используйте их в качестве клиентов и устраняйте дефекты по мере их обнаружения, в противном случае вы можете стать ответственным за код, выходящий за рамки вашей работы. Если вы находитесь в гибкой среде, это может не иметь значения, но для меня это может стать проблемой, если вдруг стать владельцем изменения кода, о котором я не могу сказать.
Одно из соображений, которое следует учитывать при этом, заключается в том, как часто указанные библиотеки используются повторно. Если они, как правило, используются в совершенно разных проектах, вы должны быть осторожны, чтобы не загнать себя в угол, где вы обнаружите, что изменения, внесенные вами три недели назад в библиотеку для поддержки какого-то нового приложения, оказались критическими изменениями для несколько других приложений.
В основном я говорю о том, что вы не хотите сопротивляться искушению внести изменения в библиотеку волей-неволей; Лучше не ставить это искушение перед собой в первую очередь. Если библиотека предназначена для повторного использования, любые существенные изменения в ней должны быть спроектированы и реализованы очень тщательно и тщательно протестированы на всех зависимых библиотеках / приложениях. Становится значительно труднее применять дисциплинированный подход, когда источник буквально находится прямо перед вами, ожидая изменения.
Мой подход заключается в создании решений для связанных библиотек ; например, у меня может быть одна сборка для основных интерфейсов и абстрактных классов, несколько других сборок для различных конкретных реализаций, другая для модульных тестов и так далее. Если есть уровни зависимых многоразовых библиотек, то часто все они будут объединены в одно и то же решение.
Но это останавливается на уровне приложений. Любой проект, который не всегда будет развертываться с базовыми библиотеками, не имеет общего решения, он просто ссылается на скомпилированную DLL. Это заставляет меня дисциплинированно относиться к изменениям библиотеки и не начинать настраивать ее, чтобы поддерживать какую-то конкретную функцию пользовательского интерфейса.
Я не знаю, является ли это «правильным» подходом, но меня раньше кусали, внося преждевременные изменения в библиотеки без должного тестирования зависимостей, и это всегда было результатом слишком большого внимания к одному приложению, а не думать о побочных эффектах. Я считаю, что когда вы работаете с библиотекой, вам нужно сосредоточиться на самой библиотеке , а не на том, как она используется в конкретном сценарии.
В ситуации, когда библиотека повторно используется несколькими независимыми решениями или когда библиотека управляется другой командой, а не той командой, которая ее использует, я думаю, что наиболее важным правилом, о котором следует помнить, является то, что конкретная версия решения обычно должен быть связан с определенной версией этой библиотеки.
Задайте себе следующий вопрос: какую версию библиотеки я получу, когда проверю исходный код решения шесть месяцев назад? Если ответ: «Всегда самая новая версия библиотеки», это может вызвать проблемы.
Я работал над проектом, в котором разработчики автоматически публиковали новые версии своих dll в локальной сети. Решение, над которым мы работали, просто ссылалось на библиотеки DLL из этого конкретного места. Проблема заключалась в том, что мы никогда не знали, для какой версии библиотеки мы компилируем, и более одного раза после тестирования мы выпускали версию нашего приложения, которая ломалась, потому что внезапно была выпущена новая версия этой библиотеки (что мы не знали). не тест).
Но это станет еще более очевидным, когда вы разрабатываете версию 2 своего приложения, но все равно должны поддерживать выпущенную версию 1 вашего приложения. Вы хотите выпустить патчи версии 1 с той же версией библиотеки, с которой она была изначально выпущена (когда ошибки нет в этой библиотеке), потому что в противном случае вам придется повторно протестировать все приложение снова.
Из-за этого я обычно добавляю все библиотеки, которые использую (которые по умолчанию отсутствуют в GAC), как часть своего решения и возвращаю их в систему управления версиями.Таким образом, у меня есть полный контроль над версиями, которые решение использует в любой момент времени.