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

Question

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

Например:

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

и т.д.

EDIT

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

Answer 1

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

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

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

---

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

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

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

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

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

Answer 2

Мы придерживаемся следующих принципов:

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

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

Answer 3

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

Answer 4

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