Причины разделить проект на несколько проектов?

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

Конечно, просто когда думаешь о том, что происходит в конкретной функции / классе / файл, где указаны границы, является делом искусства, а не науки.

Некоторыми причинами являются

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

Сокращает время компиляции - библиотека уже выполнена; вам не нужно перестраивать его во время компиляции, просто сделайте ссылку на него (при условии, что вы работаете на C ++).

Развязка - заключая ваши классы в отдельные библиотеки, вы можете уменьшить взаимосвязь и позволить вам повторно использовать библиотеку для других целей. Аналогично, пока интерфейс библиотеки не меняется, вы можете вносить изменения в библиотеку сколько угодно, а другим пользователям, которые ссылаются на нее, вообще не нужно менять свой код. Библиотеки DLL полезны в том аспекте, что не требуется повторной компиляции, но с ними может быть сложно работать, если многие приложения устанавливают разные версии одних и тех же DLL. Вы можете обновлять библиотеки, не затрагивая клиентский код. Хотя вы можете сделать то же самое только с папками, нет явного механизма для принудительного выполнения этого поведения.

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

Лицензирование / коммерциализация - Я думаю, это совершенно очевидно.

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

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

Лицензирование / коммерциализация - Я думаю, это совершенно очевидно.

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

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

Лицензирование / коммерциализация - Я думаю, это совершенно очевидно.

нет явного механизма, который бы заставлял это поведение.

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

Лицензирование / коммерциализация - Я думаю, это совершенно очевидно.

нет явного механизма, который бы заставлял это поведение.

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

Лицензирование / коммерциализация - Я думаю, это совершенно очевидно.

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

1. Повторное использование кода. Допустим, у вас есть проект A, и вы запускаете новый проект B, который имеет многие из тех же функций, что и проект A. Имеет смысл вытащить общие части A и превратить их в библиотеку, которая может использоваться как A, так и B Это позволяет иметь код в обоих местах без необходимости поддерживать один и тот же код в двух местах.

2. Повторное использование кода, инвертированное. Допустим, у вас есть проект, который работает на одной платформе. Теперь вы хотите, чтобы он работал на двух платформах. Если вы можете отделить код, зависящий от платформы, вы можете запускать разные проекты для каждой библиотеки, зависящей от платформы, а затем скомпилировать свою центральную базу кода с разными библиотеками для разных платформ.

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

Вместо ставя под сомнение ценность кода в нескольких сборках, подвергайте сомнению ценность объединения всего вашего кода в одном месте.

Вы бы поместили все на своей кухне в один шкаф?

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

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

В проектах говорится: «Эти концепции тесно связаны, и только периферийно связаны с другими концепциями»

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

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

В проектах говорится: «Эти концепции тесно связаны, и только периферийно связаны с другими концепциями»

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

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

В проектах говорится: «Эти концепции тесно связаны, и только периферийно связаны с другими концепциями»

По иронии судьбы отказ от организации через сборки мешает компилятору определить ситуацию за вас.

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

В проектах говорится: «Эти концепции тесно связаны, и только периферийно связаны с другими концепциями»

По иронии судьбы отказ от организации через сборки мешает компилятору определить ситуацию за вас.

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

В проектах говорится: «Эти концепции тесно связаны, и только периферийно связаны с другими концепциями»

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

В проектах говорится: «Эти концепции тесно связаны, и только периферийно связаны с другими концепциями»

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

В проектах говорится: «Эти концепции тесно связаны, и только периферийно связаны с другими концепциями»

Здесь есть несколько хороших ответов, поэтому я постараюсь не повторяться.

Одним из преимуществ разделения кода на собственный проект является повторное использование сборки в нескольких приложениях.

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

Другой причиной разделения может быть разрешение небольших инкрементных развертываний после того, как приложение находится в производстве. Позволять' s говорят, что у вас возникла аварийная производственная ошибка, которую необходимо исправить. Если небольшое изменение требует перестройки всего приложения (одного проекта), вам может быть сложно оправдать небольшой цикл тестирования для QA. Вам было бы легче продать, если бы вы развертывали только одну сборку с меньшим набором функций.