我正在使用rails spree commerce安装上相当大且非常定制的ruby。我正在努力决定如何最好地构建它，以便我可以继续升级狂欢而不用担心它会破坏我的修改。
在过去，我遵循了一般的狂欢文档，并通过使用装饰器，覆盖和有时完全覆盖视图进行了修改。这很好，但有两个问题。
1。）当通过装饰器打开和扩展类时，可能更难推理程序。如果您可以打开文件，例如Spree :: Product并查看代码，然后按照您的方式向前推进，而不是知道系统中的各个部分正在打开和修改类，那就容易多了。
2。）如果沿着这条路走下去，很难升级Spree。如果你已经覆盖了一个视图，并且它在下一个版本的狂欢中发生了变化，你将无法知道。您所能做的只是升级，并希望您的某个测试或手动测试能够在发生故障时进行升级。
然而，上述的好处当然是它是一个非常简单的方法来开始修改，如果你做了一些很小的修改，那么它可能很好。
但是有更好的选择吗？我一直在考虑的一种方法是简单地分配Spree并直接在分叉的狂欢代码库中进行更改。当我想要升级时，我可以简单地将任何新的更改从spree拖到我的fork repo中。这种方法的优点是，只要我覆盖的视图发生了变化，git就会通知我。然后我可以手动合并这个并忽略它或采取行动。有人在这里做过这个吗？我有什么缺点可以忽略吗？
答案 0 :(得分：0)
Spree仍处于快速发展阶段。每个次要版本凹凸都与先前版本有明显差异。其中一些变化很糟糕，大多数变化都很好。如果您正在运行Spree 2.0，例如，由于运输大修，它有利于升级，并且当我们接近2.2.3 / 2.3时，会有许多优化和重构进入管道。 / p>
大多数使用spree的商店往往拥有大型代码库，或者依赖于大量扩展。虽然我同意将class_eval用于所有内容通常不赞成，但它比自己分散spree项目更好。我们已经为我们的一个项目维护了一个狂欢叉子，它通常涉及有时痛苦的重新基础，以便从狂欢中获得好处。一般来说，我认为编写扩展或装饰类是定制应用程序的最佳方式，当事情升级时会发生故障。考虑到你负责任的装饰，通常需要更少的时间来修理破损的东西，而不是保持单独的狂欢叉。
您决定如何修改类和视图。有一些方法可以减少干扰，因此在变化时更灵活。当过滤器执行时会有直接的重新定义方法，或者在重写时会复制视图，这些是在权衡成本时必须做出的选择，而不是维护自己的自定义功能。
TL; DR除非您正在改变狂欢，否则您希望以pr为单位发送回狂欢，我建议您不要为了您的目的而自行调整狂欢。如果你想要转向更新的版本，它是技术债务的重要来源。