Вопрос о структуре проекта приложения

Question

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

1. Клиент 1 имеет стандартные функции, но также нуждается в функции поиска.
2. Клиент 2 имеет только стандартные функции.
3. Клиент 3 имеет стандартные функции и также хочет иметь календарь сотрудников.

Как бы вы решили это?

Будет ли у вас один проект, из которого вы развернете все приложение, а затем будете иметь какой-то конфигурационный файл, чтобы определить, какие функции доступны в конкретном приложении?

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

Любые другие предложения приветствуются.

Приложение разработано на Delphi и C #.

Answer 1

Одна версия для каждого клиента не очень хорошая идея, ИМХО. Это застрянет ваши продажи один день или позже.

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

Или вы также можете разрешить доступ ко всем функциям для тестирования, но заблокировать печать или сохранение - просто чтобы клиент подумал о том, чтобы потратить немного денег на эту «приятную добавленную функцию».

Иногда, имея все функции, можно создать приложение «Gasworks». Возможно, вам понадобится отдельное приложение для настройки, чтобы настроить приложение в соответствии с потребностями вашего клиента. Стоит подумать об этой архитектуре.

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

Answer 2

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

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

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

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

Answer 3

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

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

Option1.

1. Внесение общей функциональности в основной проект (Core)

2. Дополнительные вещи, такие как календарь, помещенные в отдельные проекты DLL (по одному на функциональность)

3. Создание VS SOLUTIONS, где вы объединяете все проекты для конкретной настройки + Core. Таким образом, customer1 будет иметь Customer1Silution с Core и все дополнительные проекты, в которых он нуждается, customer2 - свое решение с Core и дополнительные компоненты.

Option2.

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

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

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

Вариант 1 простой и быстрый, но если количество клиентов и конфигурация откладываются, вы столкнетесь с проблемами масштаба.

Вариант 2 - это среднее значение между этими двумя значениями, но следите за настройкой параметров.

Учитывая тот факт, что вы ссылаетесь на проекты и не относитесь к своим библиотекам в своих решениях, если вы решите проблему в Core в одном решении, это повлияет и на все другие решения.

Answer 4

у вас есть несколько вариантов:

• помещает «стандартные функции» в отдельный модуль (и), который может использоваться / связываться другими версиями
• использовать "плагин-архитектуру" для динамической загрузки дополнительных функций

Answer 5

В дополнение к тому, что сказали другие, есть еще одна опция: условные определения.

При условной компиляции вы можете обернуть специфический для функции код с помощью IFDEFS (IFDEF EmployeeCalendar, IFDEF SearchFunction ...). Затем для каждого клиента вы копируете только файл проекта и устанавливаете условные определения в соответствии с функциями, которые вы хотите включить.

Если клиент хочет / оплачивает дополнительную функцию, вы просто добавляете ее в условные определения в файле проекта этого клиента.

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

С BPL / DLL вы можете динамически загружать дополнительные модули во время выполнения, но если это не важно в вашем случае, то условные определения могут быть хорошим выбором.

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