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

Я всегда стараюсь строго следовать принципу СУХОЙ на работе; каждый раз, когда я повторяю код из-за лени, он кусается позже, когда мне нужно сохранить этот код в двух местах.

Но часто я пишу небольшие методы (возможно, 10–15 строк кода), которые необходимо повторно использовать в двух проектах, которые не могут ссылаться друг на друга. Этот метод может быть как-то связан с сетью / строками / MVVM и т. Д., И в целом это полезный метод, не относящийся к проекту, в котором он изначально находится.

Стандартный способ многократного использования этого кода - создать независимый проект для повторно используемого кода и ссылаться на него, когда он вам нужен. Проблема в том, что мы попадаем в один из двух неидеальных сценариев:

1. В итоге мы получаем десятки / сотни крошечных проектов, каждый из которых содержит небольшие классы / методы, которые нам нужно было использовать повторно. Стоит ли создавать совершенно новый .DLLкод для крошечного кода?
2. В итоге мы получаем один проект с растущей коллекцией не связанных между собой методов и классов. Этот подход - то, что сделала компания, для которой я работал; у них был названный проект, в base.commonкотором были папки для таких вещей, как я упомянул выше: работа в сети, манипуляции со строками, MVVM и т. д. Это было невероятно удобно, но ссылки на него без необходимости тянули с собой весь ненужный код, который вам не нужен.

Итак, мой вопрос:

Как команде разработчиков лучше всего использовать повторяющиеся фрагменты кода между проектами?

Меня особенно интересует, работал ли кто-нибудь в компании, которая имеет политику в этой области, или сталкивался с этой дилеммой лично, как и я.

примечание: мое использование слов «проект», «решение» и «справочник» происходит из опыта разработки в .NET в Visual Studio. Но я уверен, что эта проблема не зависит от языка и платформы.

Если они действительно являются повторно используемыми методами / классами, вы можете записать их в небольшое количество библиотек «Swiss Army Knife». Мы делаем это довольно часто в моей компании; мы называем их каркасными библиотеками:

• Framework.Data - Утилиты для работы с запросами к базе данных.
• Framework.ESB - Стандартные методы взаимодействия с нашей корпоративной сервисной шиной
• Framework.Logging - Единая система регистрации
• Framework.Services - Утилиты для взаимодействия с веб-сервисами
• Framework.Strings - Утилиты для расширенного управления строками / поиска нечетких строк и т. Д.
• ...

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

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

Я не согласен с принятым ответом по многим причинам.

По моему опыту, когда я вижу «разные» библиотеки, такие как принятый ответ, они являются оправданием, чтобы заново изобрести колесо (или не изобретено здесь (NIH) ) - гораздо больший грех, чем нарушение Dont Repeat Yourself (DRY) .

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

Подход многочисленных библиотек общего назначения является плохим примером. Это приводит к тонкой детализации сборки и слишком много сборок плохо. Недавно я сократил внутреннюю с 24 библиотек до 6 библиотек. Это улучшило время компиляции с нескольких минут до ~ 20 секунд. Visual Studio также медленнее загружается и меньше реагирует на большее количество сборок. Наличие слишком большого количества библиотек также приводит к путанице относительно того, где должен жить код; предпочитаю меньше, более простые правила.

Почему материал в .Net Framework недостаточно хорош? Фреймворк довольно большой; много раз я видел код, который повторно реализует вещи, которые уже существуют там. Действительно убедитесь, что ваши фреймворки заполняют пробелы в .Net Framework и не существуют просто по эстетическим причинам (например, «Мне не нравится .Net Framework здесь» или, возможно, какая-то преждевременная оптимизация )

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

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

Мои рекомендации:

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

Для небольших фрагментов кода - скажем, одного класса без зависимостей - мы склонны просто копировать и вставлять код в проекты. Это звучит как нарушение СУХОГО, и я признаю, что это может быть время от времени. Но в долгосрочной перспективе это было намного лучше, чем иметь какой-то масштабный проект с несколькими головами по нескольким причинам.

Во-первых, проще иметь код под рукой, особенно при сборке и отладке.

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

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

Второе решение, которое вы описываете, не так уж плохо. В .NET вы также ссылаетесь на сборку из GAC, даже если вы используете только один ее класс. «Перетаскивание неуместного кода» - это не проблема, как вы думаете. В этом случае жизненно важно, по крайней мере, поддерживать чистоту организации связанных методов и классов в разных пространствах имен. Кроме того, следует применять передовые методы для разработки API, чтобы это решение не стало беспорядочным.

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

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

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

Если проекты достаточно гранулированные и пространства имен разумны, я вижу, что это становится популярным подходом в некоторых местах.

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

GitHub имеет довольно полезный инструмент для сохранения фрагментов кода https://gist.github.com/

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

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

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

Тогда вам нужно убедиться, что вы знаете область, в которой вы хотите это сделать. Команда? Проект? Департамент? Компания? В зависимости от ответа вид кода, который вы будете вставлять в такие решения, будет зависеть от степени детализации, с которой вы настраиваете dll. Как только вы определились с этим, кто-то (желательно с некоторым энтузиазмом к идее - вы?) Должен сесть и начать вносить некоторую структуру в это.

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

Я часто сталкиваюсь с проблемой, и мое предпочтительное решение - разместить код в репозитории с поддержкой github / pubic. это решает много проблем -

1. легкий доступ и легко поделиться. cvs / svn / enterprise-repos означает извлечение проекта в несколько рабочих пространств IDE, а иногда и необходимость переключения рабочих пространств или компьютеров только для ссылки на небольшой фрагмент кода.
2. если предположить, что эти фрагменты кода не являются частными / классифицированными частями кода и являются вариациями общедоступных знаний, размещение их в общедоступном репозитории, таком как github, означает, что другие будут смотреть на него и даже могут внести свой вклад.
3. размещение чего-либо в открытом доступе под вашим именем создает дополнительную репутацию. вы будете дважды проверять и обновлять вещи, так как это отражается на ваших способностях программиста.
4. Обновления. Суть сохранения фрагментов кода в репозитории заключается в том, что если фрагмент не использовался долгое время, он может устареть (содержать устаревшие apis / libs). пример - фрагмент кода Java для чтения файла. вы могли бы найти лучший способ сделать это в 2009 году, но в 2014 году выходит новый файл API, который все меняет. твой фрагмент? все еще застрял в 2009 году. в публичном репо все будет обновляться, либо вами (потому что пункт 3), вашими товарищами по команде или кем-то из общего числа программистов, и в процессе вы можете даже получить предложения по исправлению чего-то, что Вы, возможно, делали неправильно в течение долгого времени.

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

У нас есть отдельный проект «Утилиты», где мы храним все эти небольшие методы вместе с тестами.

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

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

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

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

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

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

Я недавно придумал этот сервис: Snip2Code ( http://www.snip2code.com ).

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

Более того, существует множество сценариев, когда использование общей библиотеки просто не применимо: давайте рассмотрим, например, некоторые шаблоны проектирования, такие как Singleton, Strategy или Observer. Вы можете создавать библиотеки для поддержки таких шаблонов, но при этом нет 100% покрытия.

Реальная потребность в том, чтобы иметь инструмент для обмена общими практиками в команде. Я пытался использовать суть Github, но я застрял с их поиском (очень плохо) и с тем фактом, что я не могу поделиться ими только с моей командой, а не с другими ...

(Отказ от ответственности: я один из основателей Snip2Code, и я - вместе с моими соучредителями - некоторое время назад придерживался того же мнения: именно поэтому мы решили начать этот проект !!)