Реорганизация проекта для расширения / повторного использования

Question

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

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

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

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

1. Каждый рынок - это отдельный проект, общие черты между проектами перемещаются в общую библиотеку, проекты развертываются независимо.
2. Расширение существующего проекта для нескольких рынков, ограничение функциональности на основе приобретенной лицензии.
3. Создание родительского приложения и редизайн проектов в виде плагинов, приобретаемых отдельно

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

Есть ли какие-нибудь хорошие ресурсы по плюсам и минусам этих разных архитектур?

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

Answer 1

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

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

---

1. Каждый рынок - это отдельный проект

Хорошее решение, если вы собираетесь разрабатывать одновременно для нескольких рынков.

Плюсы:

• Это позволяет разработчикам для рынка A ломать сборку A, не мешая текущей работе над B
• Это значительно снижает вероятность того, что изменение, сделанное для рынка A, вызовет ошибку для рынка B

Минусы:

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

2. Расширить существующий проект, чтобы охватить несколько рынков

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

Плюсы:

• Работа с лицензией, вероятно, в любом случае полезна, даже если вы двигаетесь в направлении (1) или (3).
• Единая кодовая база позволяет проводить рефакторинг на всех рынках.

Минусы:

• Даже если вы просто работаете над чем-то для рынка A, вам придется создавать и поставлять код для рынков B, C и D - хорошо, если у вас небольшая кодовая база, но она становится все более раздражающей по мере получения на тысячи классов
• Изменения одного рыночного риска, нарушающие код для других рынков
• Изменения на одном рынке требуют повторного тестирования других рынков

3. Создать родительское приложение и перепроектировать проекты как плагины

Технически приятен на ощупь и может позволить вам поделиться большим количеством кода.

Плюсы:

• Все плюсы (1), потенциально плюс:
  • более четкое разделение общего и рыночного кода
  • может позволить вам перейти к общедоступному API, который позволит перекладывать часть вашей работы на ваших клиентов и / или продавать прибыльные сервисные проекты

Минусы:

• Все минусы (1), плюс требует еще большего рефакторинга.

---

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

Зависит ли вы от (1) или (3) вида, зависит. В основном все сводится к тому, кто «отвечает»: общий код или код, специфичный для рынка? Граница между плагином и классом контроллера, который настраивает некоторый общий компонент, может быть довольно размытой. Мой совет: пусть код скажет вам, что ему нужно.

Answer 2

Вы сказали «копирование и разветвление», что заставляет меня думать, что, возможно, вы не рассматривали управление этим «форком» как ветку в системе контроля версий, такой как SVN. Делая это таким образом, когда вы реорганизуете ветку для размещения в другой отрасли, вы можете объединить эти изменения обратно в основной ствол с помощью системы контроля версий.

Если вы придерживаетесь долгосрочной стратегии перехода к одному приложению, где все варианты контролируются файлом конфигурации (или базой данных конфигурации SQLITE), тогда этот подход вам поможет. Вам не нужно ничего объединять, пока вы не уверены, что обобщили это для обеих отраслей, так что вы можете создавать две уникальные системы столько, сколько вам нужно. Но вы не загоняете себя в угол, потому что все это в одном дереве исходного кода, магистрали для унаследованной отрасли и одной ветке для каждой новой отрасли.

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

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

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

Answer 3

1) НЕТ! Вы не хотите управлять разными ветвями одной и той же кодовой базы ... Потому что, как бы ни был распространен код, вы захотите внести радикальные изменения, и один проект "на данный момент" будет не так важен, как другие , и тогда вы получите одну ветвь, растущую быстрее, чем другие .... вставьте снежок.

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

3) Это также «может» работать. Если вы используете C #, плагины относительно просты, вам нужно беспокоиться только об аде зависимости. Если у плагинов есть какой-либо шанс стать циклически взаимозависимым (то есть, a требует b, требует c, требует a), то это быстро взорвется, и вы вернетесь (довольно легко) обратно к # 2.

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

Плюсы обмена кодом: Одно изменение меняет все. Единая модель данных. Есть только одна правда. (Гораздо проще для всех быть на одной странице)

Минусы совместного использования кода: Одно изменение меняет все .. Будьте осторожны. Если в нем есть одна ошибка, это влияет на все.

Плюсы копирования / разветвления: Обычно быстрее реализовать конкретную функцию для конкретного клиента. Быстрее взломать, когда вы поймете, что допущение A применимо только для рынков B и C, а не D.

Минусы копирования / разветвления: Один или несколько скопированных проектов в конечном итоге потерпят неудачу из-за отсутствия согласованности в вашем коде. Как сказано выше: радикальные изменения занимают намного больше времени.

Удачи.