Как вы организуете свою библиотеку кода?

Question

Мне интересно знать, как люди организуют свои библиотеки кода, особенно в отношении повторно используемых компонентов.Ниже я говорю в терминах OO, но меня интересует, как вы организуете библиотеки и для других типов языков.

Например:

• Являетесь ли вы сторонником проектов библиотеки классов для всего или предпочитаете хранить все в одном проекте?
• Используете ли вы повторно готовые библиотеки DLL или включаете отдельные классы из предыдущих проектов в свою текущую работу?Если это отдельные классы, делитесь ли вы ими между проектами, чтобы убедиться, что все они поддерживаются в актуальном состоянии, или вы разрешаете ветвление?
• Насколько велики ваши многоразовые элементы?Насколько они сосредоточены?Как они сфокусированы?
• Какого уровня повторного использования вы достигаете с помощью ваших предпочтительных практик?

и т.д.

Редактировать

Я не ищу здесь конкретных указаний, меня просто интересуют мысли и практики людей.Меня особенно интересует повторное использование кода между разрозненными проектами, а не в рамках одного проекта.(К сожалению, использование "project" здесь вводит в заблуждение - я имею в виду повторное использование между реальными проектами, выполняемыми для клиентов, а не проектами в смысле Visual Studio.)

Answer 1

Как правило, этим можно руководствоваться развертывание соображения:

Как вы будете развертывать (т.е.что вы будете копировать на своем производственном компьютере)?

Если то, что вы развертываете, является упакованный компоненты (т.е.dll, jar, war, ...), разумно организовать "библиотеку кода" как набор упакованный набор файлов.
Таким образом, вы будете разрабатывать непосредственно с помощью -- dll, jar, war, ...-- который будет развернут на производственной платформе.
Идея заключается в том,:если он работает с этими упакованными файлами, он все еще может работать в рабочей среде.

---

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

Я утверждаю, что такое повторное использование проще при "компонентном" подходе (подобном тому, который обсуждался в вопросе "Филиалы поставщиков в GIT")

В рамках более чем 40 текущих проектов мы достигли:

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

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

Answer 2

Мы следуем этим принципам:

• Принцип эквивалентности выпуска и повторного использования:Гранула повторного использования - это гранула высвобождения.
• Общий Принцип закрытия:Классы в пакете должны быть закрыты вместе для защиты от изменений одного и того же типа.
• Общий Принцип повторного использования:Классы в пакете повторно используются вместе.
• Принцип Ациклических зависимостей:Не допускайте циклов в графике зависимостей пакета.
• Принцип стабильной зависимости:Зависеть в направлении стабильности.
• Принцип стабильной абстракции:Пакет должен быть настолько же абстрактным, насколько и стабильным.

Вы можете узнать больше по здесь и над здесь.

Answer 3

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

Answer 4

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