В поисках лучших практик.Каковы некоторые преимущества и недостатки расширения стороннего продукта, позволяющего объединять новые версии настолько легко, насколько это возможно - PullRequest
2 голосов
/ 07 июля 2011

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

Итак, что я ищу, так это некоторые рекомендации, лучшие практики, дозы и пожертвования и т. Д. Помните, что я беру на себя эту задачу.

Единственные действительно твердые вещи, которые я планирую сделать наверняка, это.

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

Кроме этого, я просто планирую сохранитьшаблоны Decorator, Facade, Proxy и Adapter находятся под рукой, и постарайтесь сделать это максимально безболезненно в будущем.

Любой вклад приветствуется, спасибо.

Ответы [ 4 ]

2 голосов
/ 07 июля 2011

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

2 голосов
/ 07 июля 2011
  1. В вашем ядре приложения определите интерфейс для любых услуг, предоставляемых сторонним продуктом.

  2. На вашем уровне инфраструктуры внедрите каждый интерфейс как Adapter / Wrapper для стороннего продукта.

  3. Код против интерфейса везде в вашем приложении. Используйте Inversion of Control для регистрации реализаций ваших сервисных интерфейсов и автоматического разрешения сконфигурированной реализации по типу интерфейса и контексту. Моя любимая библиотека IoC: StructureMap .

Результат,

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

1 голос
/ 07 июля 2011

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

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

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

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

1 голос
/ 07 июля 2011

Не решение, а совет:

Твоя вторая «солидная вещь» станет отличным активом, когда тебе понадобится обновить.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...