我想知道在我们的Rails应用上做一些扩展，我想使用Golang。 那么，今天我们在RoR中编写了相当大的应用程序，其中有很多处理和处理。计算通过Ruby进行，在某些情况下变得很慢。
我想知道我们应用程序的某些部分，并为了更好的性能在Golang中重新编写它们。
我想听听一些好的建议＆amp;实践，特别是如何开始拆分它们。
最好的问候
答案 0 :(得分：1)
如何最好地吃大象？一次咬一口......
因为这对你来说是一个新的世界，所以我首先要剥离你的应用程序中与其他任何东西没有高度连接的一个函数。选择不使用任何实际业务逻辑的报告引擎或直接或类似地查询数据库的定期维护任务。它不一定是最需要的性能增强（尽管如果必须通过业务逻辑来获取数据，IME报告几乎总是更慢）。重点是剥离一些没有巨大先决条件的东西，以便您获得对新环境如何插入的信心和理解。
有了这些，请考虑您需要多少业务逻辑以及您的副作用有多深。尝试在没有太多副作用且尽可能接近经典函数（即一堆输入，一个输出）的事情中找到你的第二批作品。如果您的RoR代码中有某些内容可以发送（比如“我得到了所有这些数据”......那么就会发生一些神奇的事情......然后“我输出一些处理过的数据”），这是一个不错的选择。
在HTTP上来回跳转会增加一定的延迟（如果直接来自浏览器，则会更少，但仍然......），所以要小心在可以获得收益的地方工作。针对您的旧代码的分析器将有助于在这里聚集 - 无论您的下一个候选人是多么昂贵。
如果您在处理好后果仍然需要优化，那么您可能需要考虑拆分业务规则，使一些人生活在RoR世界中，而其他人则生活在Go中。不要保持同样的业务规则的两个实施 - 这就是说有道理。如果您认为订单是一个系统而供应链是另一个系统，那很好，但不要试图在两种环境中维护供应链代码的实现。
对于G-d而言，如果您将业务逻辑从旧系统迁移到新系统，请不要将旧代码放在原地但未使用！你有版本控制 - 如果有人需要回顾旧的实现，让他们挖掘。否则，你会将糟糕的代码维护者与永远不会运行的残留代码混淆。如果您已弃用代码，请删除它。
哦，我确定我不需要这样说，但你需要进行单元测试来验证bug-for-bug兼容性......
最后，请记住，RoR是高度MVC导向的，而Go不是固有的 MVC（尽管有number of frameworks ）。你肯定想要检查（并且诚实地丢弃）这些框架，徒劳地尝试做一个直接端口。来吧：把它从你的系统中拿出来。然后继续做小的增量进步，然后慢慢吃掉你的大象。