分叉与覆盖

Question

我正在开发一个相当大且相当定制的 ruby​​ on rails spree 商业安装。我正在尝试决定如何最好地构建它，这样我就可以继续升级大礼包，而不必担心它会破坏我的修改。

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

1.) 当类通过装饰器打开和扩展时，对程序的推理可能会更加困难。如果您可以打开文件，例如 Spree::Product 并查看代码，然后按照祖先的顺序工作，而不是知道在系统的各个部分中正在打开和修改类，它会容易得多。

2.) 如果你走这条路，升级 Spree 可能会很困难。如果您覆盖了一个视图并且它在下一个版本的 spree 中发生了变化，您将无法知道。您所能做的就是升级并希望您的一项测试或手动测试在它出现故障时将其恢复。

然而，上述的好处当然是它是一种开始修改的非常简单的方法，如果您只进行少量和小的修改，那么它可能没问题。

但是有更好的选择吗？我一直在考虑的一种方法是简单地分叉 Spree 并直接在分叉的 spree 代码库中进行更改。然后，当我想升级时，我可以简单地将任何新的更改从 spree 中提取到我的分叉存储库中。这种方法的优点是，只要我覆盖的视图发生更改，git 就会通知我。然后我可以手动合并它并忽略它或采取行动。这里有没有人在实践中这样做过？有没有我忽略的缺点？

Answer 1

Spree 仍在快速发展中。每个次要版本的凹凸都与以前的版本有明显的不同。其中一些变化是坏的，大多数这些变化是好的。例如，如果您正在运行 Spree 2.0，那么升级是有益的，因为要进行运输大修，并且随着我们接近 2.2.3/2.3，会有许多优化和重构即将到来。

大多数使用 spree 的商店往往拥有庞大的代码库，或者依赖于大量的扩展。虽然我同意为所有事情都去 class_eval 通常是不赞成的，但它比你自己分叉狂欢项目要好。我们有一个狂欢分叉，我们必须为我们的一个项目维护它，它通常涉及有时痛苦的重新基础，以便从狂欢中获得收益。一般来说，我认为编写扩展或装饰类是自定义应用程序的最佳方式，确保升级时出现问题。考虑到您负责地装饰，修复损坏的东西通常比维护单独的狂欢叉花费更少的时间。

如何修改类和视图由您决定。有一些方法可以减少干扰，因此在变化发生时更灵活。当使用前置过滤器时，有直接的重新定义方法，或者当覆盖时复制视图，这些是您在权衡这样做的成本与维护自己的自定义功能时必须做出的选择。

TL;DR 除非您对 spree 进行了更改，否则您希望将 spree 作为 pr 发送回 spree，我建议您避免分叉 spree，只是为了根据您的目的对其进行自定义。如果您打算迁移到新版本，这将是一大笔技术债务。