На работе я всегда стараюсь строго следовать принципу DRY; каждый раз, когда я повторяю код из лени, он возвращается позже, когда мне нужно поддерживать этот код в двух местах.
Но часто я пишу небольшие методы (может быть, 10 - 15 строк кода), которые нужно повторно использовать в двух проектах, которые не могут ссылаться друг на друга. Метод может быть как-то связан с сетями / строками / MVVM и т.д. и является в целом полезным методом, не специфичным для проекта, в котором он изначально находится.
Стандартным способом повторного использования такого кода было бы создание независимого проекта для повторно используемого кода и ссылка на этот проект, когда он вам нужен. Проблема заключается в том, что мы попадаем в один из двух менее идеальных сценариев:
.DLL
только для крошечного кусочка кода?base.common
, в котором были папки для таких вещей, как я упоминал выше: работа с сетью, работа со строками, MVVM и т.д.. Это было невероятно удобно, но обращение к нему без необходимости тянуло за собой весь нерелевантный код, который вам был не нужен.Поэтому мой вопрос заключается в следующем:
Как команде разработчиков лучше всего повторно использовать небольшие фрагменты кода между проектами?.
Мне особенно интересно, если кто-то работал в компании, которая имеет политику в этой области, или кто сталкивался с этой дилеммой лично, как я.
примечание: Я использую слова "проект", "решение" и "ссылка" из опыта разработки .NET в Visual Studio. Но я уверен, что этот вопрос не зависит от языка и платформы.
Если это действительно многократно используемые методы / классы, вы можете записать их в небольшое количество 'швейцарских армейских ножей' библиотек. В моей компании мы делаем это довольно часто; мы называем их библиотеками фреймворков:
Framework.Data
- утилиты для работы с запросами к базе данных.Framework.ESB
- Стандартные методы для взаимодействия с нашей сервисной шиной предприятия.Framework.Logging
- Унифицированная система протоколированияFramework.Services
- Утилиты для работы с веб-сервисамиFramework.Strings
- Утилиты для расширенного манипулирования строками / нечеткого поиска строк и т.д.В целом, существует около дюжины библиотек. Вы можете распределять код по своему усмотрению, так что вам не придется создавать сотни библиотек или сваливать все в одну гигантскую сборку. Я нахожу такой подход подходящим, потому что только некоторым из наших проектов понадобится Framework.Data
и только немногим - Framework.Strings
, поэтому потребители могут выбрать только те части фреймворка, которые имеют отношение к их конкретному проекту.
Если это действительно просто фрагменты, а не реальные методы / классы, которые могут быть легко использованы повторно, вы можете попробовать просто распространить их как фрагменты кода в IDE (например, Visual Studio Code Snippets). Команды, в которых я работал в прошлом, имели общую библиотеку сниппетов, что облегчало всем следование нашим стандартным практикам кодирования и во внутреннем коде.
Я не согласен с принятыми ответа по многим причинам.
По моему опыту, когда я вижу, что "Разное" в библиотеках, как принято отвечать, они'вновь предлог, чтобы изобретать велосипед (или изобретено не здесь(низ)) - гораздо больший грех, чем нарушение не повторять себя (сухие).
Иногда нарушает сухой закон может быть разумный компромисс, это лучше, чем введение жесткой связи. Повторное использование является вторичным по сравнению с хорошим объектно-ориентированного проектирования. Немного (я имею в виду небольшое количество, применить правило трех) дублирования легче понять, чем базовый спагетти-код.
Подход многочисленными библиотеками общего назначения, подает плохой пример. Это приводит к зависимости от уровня сборки и слишком много сборок-это плохо. Недавно я уменьшил в доме из 24 библиотек в 6 библиотеках. Он улучшил время компиляции от нескольких минут до ~20 секунд. В Visual Studio это также медленнее, чтобы загрузить и менее гибкой с несколько сборок. Слишком многие библиотеки также приводит к путанице, где код должен жить, предпочитаю меньше, проще правила.
Почему вещи в интернет .Net фреймворка не достаточно хорошо? Рамках довольно большой; много раз я'вэ видел код, который вновь реализует материал, который уже существует. Действительно убедитесь, что ваши рамки заполняют пробелы в .NET, и не просто существует по эстетическим соображениям (например "Я не'т нравится .Чистая рамок здесь" или, возможно, некоторые преждевременная оптимизация)
Представляем еще один слой в архитектуре имеет значительную стоимость сложности. Почему слой существует? Я'вэ видел ложного повторного использования, что я имею в виду, что код построен на вершине собственной базы. Было бы гораздо более эффективно реализовать его непосредственно на верхней части стандартной библиотеки.
С использованием стандартизированных технологий (как .NET и популярных 3 участника/библиотеки с открытым исходным кодом) преимущества часто перевешивают сравнительные технологические достижения дома сами. Легче найти талант, который знает эти технологии и существующие разработчики будут больше инвестировать в обучение.
Мои рекомендации:
Для небольших кусочков кода-скажем, один класс без зависимости, мы, как правило, просто скопируйте и вставьте код в проектах. Это звучит, как нарушение сухого, и я'Лл признать, он может быть в разы. Но в долгосрочной перспективе это гораздо лучше, чем какие-то массивные, многоголовые Викискладе по нескольким причинам.
Во-первых, это просто проще, чтобы код удобно, особенно при построении и отладке вещи.
Во-вторых, неизменно вы'll хочу сделать некоторые немного подправить, чтобы общий код для этого проекта. Если вы'ве получил локальную копию источника, чем вы можете просто сделать настройки и назвать это день. Если есть общая библиотека, то вы могли бы быть взяв на настройки этой библиотеки, а затем убедившись, что вы Дон'т сломать все другие приложения или создать кошмар версий.
Так что, если это'т достаточно крепкий для это'собственные пространства имен мы, как правило, просто вставьте его в соответствующие биты на проект и назовите его день.
Второе решение, которое вы описали, не так уж плохо. В .NET вы также ссылаетесь на сборку из GAC, даже если используете всего один класс из нее. 'Перетаскивание неактуального кода' не такая уж проблема, как вы думаете. В этом случае жизненно важно, по крайней мере, держать связанные методы и классы чисто организованными в разных пространствах имен. Кроме того, следует применять передовые методы проектирования API, чтобы предотвратить превращение этого решения в беспорядок.
Если речь идет об очень маленьких кусочках кода, я думаю, что следующий подход является хорошим дополнением к общему проекту: Разрешите дублировать их в разных решениях. Поступайте с ними как с лучшими практиками: документируйте и сообщайте о них команде.
Я'вэ только когда-либо работал в "предприятия" местах, где такого рода вещь была вопрос, и каждый раз, когда он'был второй вариант, что'ы были приняты. По большей части это'ов работала нормально, потому что там ничего'т-либо ограничений на присутствие приложения.
Однако, проведя на прошлой неделе с запуска людей, строящих свой собственный NuGet для сервера Я'м склонен рекомендовать это в качестве жизнеспособной альтернативы. Конечно, вопросы я ожидаю, что появляться будет вокруг знакомства-возможность.
Если проекты достаточно зернистый и пространства имен дельное, то я вижу, что это становится популярным подходом в местах.
Я'вэ недавно об этом думала и что приходило мне в голову, была большая библиотека из распространенных методов, как уже было сказано до сих пор, но с изюминкой. Проект библиотеки позволит вам настроить во время компиляции, какие части включаются вроде как проект busybox и. С таким подходом, вы можете есть кухня, библиотека стиль раковина РЕПО, но возьмите только необходимые инструменты при компиляции.
GitHub есть очень полезный инструмент для сохранения фрагментов кода https://gist.github.com/
Он хранит ваши сниппеты в виде git-репозиториев, которые вы можете сохранить в тайне, или использовать для обмена фрагментами с другими людьми.
я столкнулся с проблемой много, и мой предпочтительным решением является размещение кода на GitHub/лобковые веб-репозитория. это решает много проблем -
Одна вещь, которую я бы порекомендовал - не важно, где вы храните ваши сниппеты, Гугл вещи, прежде чем использовать его. вещи все время меняются. сохраненные фрагменты сэкономить время, но и привести к самоуспокоенности.
В зависимости от размера команды/проекта/компании это будет довольно сложно сделать эффективно, если только это не встроено в вашу среду каким-то образом, и каждое решение, которое вы найдете (если вы его внедрите), будет стоить определенных денег. (Возможно, оно будет стоить вам больше, но это вы не сможете легко измерить). Вам придется проверить, стоит ли оно того. Помните также, что многоразовые решения имеют тенденцию становиться абстрактными и часто подходят для многих ситуаций, но не являются оптимальными.
В любом случае, если вы хотите сделать это для кода, созданного более чем одним человеком, сначала вам'понадобится осознание всех и сотрудничество. Это включает разработчиков и менеджеров.
Затем вам нужно убедиться, что вы знаете, в какой области вы хотите это сделать. Команда? Проект? Отдел? Компания? В зависимости от ответа будет варьироваться тип кода, который вы вложите в такие решения, а также степень детализации, с которой вы настроите dll. Как только вы определились с этим, кто-то (предпочтительно с энтузиазмом к этой идее - вы?) должен сесть и начать создавать структуру.
Однако, простого создания таких dll будет недостаточно. Чтобы сделать их полезными, вам нужно будет рекламировать их (пользователям и соавторам) и поддерживать их как любую другую часть программного обеспечения, что обычно означает, что вам нужно назначить кого-то ответственного за них на долгое время. Вам также понадобится надежная документация, которая также будет нуждаться в поддержке. При некотором везении и сотрудничестве вы можете получить в итоге несколько лучших практик, но это также легко может перерасти в самостоятельный проект, в зависимости от размера и количества вовлеченных команд. И для этого вам все равно понадобится поддержка руководства.
У нас есть отдельный проекта "ЖКХ", где мы храним все эти методы вместе с тестами.
Когда проект нужна утилита добавляет источник файл необходимый метод с "Добавить ссылку на".
Это означает, что нет выполнения временных зависимостей добавил (если включен файл нужен).
Эта система прекрасно работала, но как и все другие, он должен diciplin на то, что это утилита. Requiering высокое тестовое покрытие работала хорошо для нас и тесты также хорошая документация по использованию. Обнаружение все еще является нерешенной проблемой для нас.
Одна сложность с помощью проекта решить уровень видимости на пункты. Правило большого пальца заключается в том, что методы должны быть внутренние и структур данных общественности.
Моя компания использует интранет-местные веб-сервисы. У нас есть несколько веб-сервисов, которые настроены как общие внутренние веб-сервисы, а для другого проекта требуется доступ к одной из услуг, он отправляет HTTP-запрос с определенным интерфейсом. Поскольку она's на интранет, размещенный в одной ферме серверов, эти запросы очень быстро.
Очевидно, это работает только с интернет-приложения (и работает только раз в миллисекунду, когда на одной и той же локальной сети), но она имеет некоторые действительно хорошие преимущества.
Недавно я придумал эту услугу: Snip2Code (http://www.snip2code.com).
Это'Очень интересный способ поделиться только фрагменты (не полностью библиотек) с вашей командой. Это нарушает привычную точку для создания общих библиотек, которые должны использоваться в других проектах, и на мой взгляд это ценное видение.
Кроме того, есть много сценариев использования общей библиотеки просто не't применяют: пусть'ы рассмотрим для примера некоторые шаблоны проектирования, как синглтон, стратегии или наблюдателя. Вы можете создавать библиотеки для поддержки таких моделей, но все-таки есть's нет 100% покрытия.
Реальная потребность-это инструмент для обмена общепринятой практикой среди команды. Я пытался использовать GitHub's в логи, но я'м застрял с поиском их (очень бедных), и с тем, что я не могу поделиться ими только между своей командой и не с другими...
(Оговорка: я'м один из основателей Snip2Code, и я был вместе с моими соучредителями- в вашем мышлении некоторое время назад: вот почему мы решили начать этот проект!!)