Forking vs overriding

Question

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

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

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

2.) Может быть сложно обновить Шпрее, если вы спуститесь по этому маршруту. Если вы переопределили представление и оно изменилось в следующей версии spree, вы не знаете. Все, что вы можете сделать, это обновить и надеяться, что один из ваших тестов или ручное тестирование подберет его, если он сломается.

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

Однако существуют ли альтернативы? Один из подходов, который я рассматривал, - это просто форсирование Spree и внесение изменений непосредственно в кодовую базу разветвленного spree. Тогда я мог бы просто вытащить любые новые изменения из spree в свое раздвоенное репо, когда захочу обновиться. Преимущество этого подхода состоит в том, что git будет уведомлять меня, когда есть изменение в представлении, которое я переопределил. Затем я могу объединить это вручную и либо игнорировать его, либо принять меры. Кто-нибудь здесь сделал это на практике? Есть ли недостатки, которые я пропускаю?

Answer 1

Spree все еще находится в стремительном развитии. Каждая младшая версия bump имеет отличия от предыдущей версии. Некоторые из этих изменений плохие, большинство из этих изменений хороши. Если вы используете Spree 2.0, например, это полезно для обновления из-за капитального ремонта, и по мере приближения к 2.2.3/2.3 существует ряд оптимизаций и рефакторинг, идущих вниз по трубе.

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

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

TL; DR, если вы не вносите изменения в веселье, вы хотели бы отправить обратно в spree как pr, я бы рекомендовал избегать форкинга, чтобы настроить его для ваших целей. Это большой источник технического долга, если вы когда-либо стремились перейти на более новые версии.