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

Question

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

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

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

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

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

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

Существуют ли какие-либо хорошие ресурсы, посвященные плюсам и минусам этих различных архитектур?

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

Answer 1

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

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

---

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

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

Плюсы:

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

Минусы:

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

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

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

Плюсы:

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

Минусы:

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

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

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

Плюсы:

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

Минусы:

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

---

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

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

Answer 2

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

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

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

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

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

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

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

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

Удачи.

Answer 3

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

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

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

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

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