Как вы организовываете свою библиотеку кода?
Мне интересно знать, как люди организуют свои библиотеки кода, особенно в отношении повторно используемых компонентов. Я говорю в терминах OO ниже, но меня интересует, как вы организуете библиотеки для других типов языков.
Например:
- Вы сторонник проектов библиотеки классов для всего или предпочитаете хранить все в одном проекте?
- Используете ли вы свои предварительно созданные библиотеки DLL или включаете отдельные классы из предыдущих проектов в текущую работу? Что касается отдельных классов, вы разделяете их между проектами, чтобы обеспечить их актуальность, или разрешаете ветвление?
- Насколько велики ваши многоразовые элементы? Насколько они сфокусированы? Как они сфокусированы?
- Какой уровень повторного использования вы достигнете через ваши предпочтительные практики?
и т.п.
РЕДАКТИРОВАТЬ
Я не ищу конкретных указаний здесь, я просто интересуюсь мыслями и практикой людей. Меня особенно интересует повторное использование кода между разрозненными проектами, а не внутри одного проекта. (К сожалению, использование "проекта" здесь вводит в заблуждение - я имею в виду повторное использование между реальными проектами, выполняемыми для клиентов, а не проектами в смысле Visual Studio.)
4 ответа
Как правило, он может быть ориентирован на развертывание:
Как вы будете развертывать (то есть, что вы будете копировать на свой рабочий компьютер)?
Если то, что вы развертываете, является упакованными компонентами (то есть dll, jar, war, ...), разумно организовать "библиотеку кода" в виде набора упакованного набора файлов.
Таким образом, вы будете разрабатывать напрямую с помощью - dll, jar, war, ... - который будет развернут на производственной платформе.
Идея такова: если он работает с этими упакованными файлами, он все еще может работать в производстве.
повторное использование кода между разрозненными проектами, а не в рамках одного проекта.
Я утверждаю, что такое повторное использование проще в "компонентном" подходе (как тот, который обсуждался в вопросе " Ветви поставщика в GIT")
За более чем 40 текущих проектов мы достигли:
- техническое повторное использование путем систематической изоляции любого чисто технического аспекта в независимой структуре (как правило, структура журнала, структура исключений, KPI - ключевой показатель эффективности - структура и т. д.).
Эти технические компоненты повторно используются в любых других проектах. - повторное использование функций путем установки четкой аппликативной архитектуры для разделения любой функциональной области (с учетом бизнес-требований и функциональных спецификаций) на четко определенные приложения. Это, как правило, включает в себя, например, уровень шины, который также является отличным кандидатом для предоставления услуг, повторно используемых любыми другими проектами.
Резюме:
Для большой функциональной области, когда один проект не поддается управлению, хорошая аппликативная архитектура приведет к естественному повторному использованию кода.
Мы следуем этим принципам:
- Принцип эквивалентности повторного использования выпуска: гранула повторного использования является гранулой освобождения.
- Общий принцип закрытия: классы в пакете должны быть закрыты друг от друга против одинаковых изменений.
- Общий принцип повторного использования: классы в пакете повторно используются вместе.
- Принцип ациклических зависимостей: не допускайте циклов в графе зависимостей пакетов.
- Принцип стабильной зависимости: зависит от стабильности.
- Принцип стабильной абстракции: пакет должен быть настолько абстрактным, насколько он стабилен.
Что бы вы ни решили, хорошее управление исходным кодом имеет решающее значение для этого, поскольку оно позволяет вам реализовывать свою стратегию любым удобным для вас способом, не получая при этом множество несвязанных копий ваших библиотек. Хорошая поддержка ветвления имеет важное значение.