分叉与覆盖

Question

我正在研究轨道狂热商务安装上相当大且相当定制的红宝石。我试图决定如何最好地设计它，以便我可以继续升级狂欢，而不用担心它会打破我的修改。

在过去，我遵循一般的狂欢文档，并通过使用装饰器，覆盖和有时覆盖视图完全修改。这工作正常，但有两个问题。

1.）当通过装饰器打开和扩展类时，可能很难推断程序。如果你可以打开这个文件，例如Spree :: Product，然后查看代码，然后在祖先中工作，而不是知道系统中各个部分的类正在被打开和修改，那么它更容易。

2.）如果沿着这条路线走下去，可能很难升级Spree。如果你已经覆盖了一个视图，并且它在下一个版本的spree中发生了变化，你就无法知道。你所能做的只是升级，希望你的一个测试或者手动测试能够在测试结束时提取。

上述的好处当然是它是一个非常简单的方式来开始修改，如果你做了很少和很小的修改，那么它可能很好。

但是，有没有更好的选择？我一直在考虑的一种方法是直接分叉Spree并直接在分叉的Spree代码库中进行更改。当我想要升级时，我可以简单地将任何新的更改从spree中拖放到我的分叉回购中。这种方法的优点是，git会在我覆盖的视图发生变化时通知我。然后我可以手动合并，并忽略它或采取行动。有没有人在这里做过这个练习？我忽略了什么缺点？

Answer 1

施普雷仍在快速发展。每个小版本的凹凸与以前的版本有明显的不同。其中一些变化很糟糕，其中大部分变化都很好。例如，如果您运行的是Spree 2.0，则由于运输检修而升级是有益的，而且当我们接近2.2.3/2.3时，会有一些优化和重构。

使用狂欢的大多数商店往往有大的代码库，或依赖于大量的扩展。虽然我同意去class_eval的一切是普遍不赞成的，它比自己的疯狂项目更好。我们有一个疯狂的分支，我们必须为我们的一个项目维护它，并且它通常会涉及到有时很痛苦的重新基地，以便从疯狂中获得好处。一般来说，我认为编写扩展或装饰类是定制应用程序的最佳方式，确保在事物升级事件中断时。考虑到你负责任地装饰，通常需要更少的时间来修理破坏的东西，而不是维持单独的狂欢叉。

这是你如何修改类和视图的决定。有些方法可以减少侵入性，因此在变更时更加灵活。直接重新定义方法可以在前置过滤器执行时执行，或者在覆盖执行时复制视图，这些都是您在衡量执行成本时所必须做出的选择，而不是维护您自己的自定义功能。

TL; DR除非你想改变狂欢你想送回疯狂的pr，否则我会建议避免分散狂欢只是为了你的目的定制它。如果您的目标是转向更新的版本，那么这是技术债务的一大来源。