在Rails应用中查找未使用的代码
我如何找到在生产中正在运行和未运行的代码？
How do I find what code is and isn't being run in production ?
该应用程序已经过良好的测试，但是有很多测试可以测试未使用的代码。因此，他们在进行测试时会得到覆盖...我想重构和清理这些混乱情况，这一直在浪费我的时间。
我有很多后台工作，这就是为什么我想要制作环境来指导我的原因。在heroku上运行，我可以加速测功机以补偿探查器对性能的影响。
The app is well-tested, but there's a lot of tests that test unused code. Hence they get coverage when running tests... I'd like to refactor and clean up this mess, it keeps wasting my time. I have a lot of background jobs, this is why I'd like the production env to guide me. Running at heroku I can spin up dynos to compensate any performance impacts from the profiler.
相关问题如何在Ruby应用中找到未使用的方法？没有帮助。
奖金：显示一行代码运行频率的指标。不知道为什么要我，但是我愿意！ ：）
Bonus: metrics to show how often a line of code is run. Don't know why I want it, but I do! :)
在正常情况下，方法是使用测试数据进行代码覆盖，但正如您所说的，的经过测试但未在生产应用程序上使用的代码中，您可以做一些稍有不同的事情。
Under normal circumstances the approach would be to use your test data for code coverage, but as you say you have parts of your code that are tested but are not used on the production app, you could do something slightly different.
首先为了清楚起见：不信任自动工具。他们只会向您显示您正在积极测试的结果。
有了我们的免责声明，我建议您使用代码覆盖率工具（例如 rcov 或 simplecov （对于Ruby 1.9） ）在您的生产应用程序上，并衡量用户实际使用的代码路径。虽然这些工具最初是用于测量测试覆盖率的，但您也可以将其用于生产覆盖率
With the disclaimer behind us, I propose you use a code coverage tool (like rcov or simplecov for Ruby 1.9) on your production app and measure the code paths that are actually used by your users. While these tools were originally designed for measuring test coverage, you could also use them for production coverage
在测试期间访问所有相关代码路径的假设下，您可以删除其余部分。不幸的是，这种假设很可能不会完全成立。因此，在删除部件时，您仍然必须运用对应用程序及其内部工作的了解。在删除声明部分（例如模型引用）时，这一点尤为重要，因为它们通常不直接运行，而仅用于配置系统的其他部分。
Under the assumption that during the test time-frame all relevant code paths are visited, you can remove the rest. Unfortunately, this assumption will most probably not fully hold. So you will still have to apply your knowledge of the app and its inner workings when removing parts. This is even more important when removing declarative parts (like model references) as those are often not directly run but only used for configuring other parts of the system.
另一种方法是可以与上述方法结合使用，以尝试将您的应用重构为可以打开和关闭的独特功能。然后，您可以关闭那些可能尚未使用的功能，并检查是否有人抱怨：）
Another approach which could be combined with the above is to try to refactor your app into distinguished features that you can turn on and off. Then you can turn features that are suspected to be unused off and check if nobody complains :)
最后一点：您将找不到一个神奇的工具来做您的完整分析。那是因为没有工具可以知道实际用户是否使用了某些代码。工具唯一可以做的就是创建（或多或少）静态可达性图，告诉您是否从某个角度调用了代码。对于像Ruby这样的动态语言，即使做到这一点也相当困难，因为面对在Rails上下文中大量使用的元编程或动态调用，静态分析不会带来太多见识。因此，某些工具实际上可以运行您的代码，或尝试从测试范围中获取见识。但是绝对没有魔咒。
And as a final note: you won't find a magic tool to do your full analysis. That's because no tool can know whether a certain piece of code is used by actual users or not. The only thing that tools can do is create (more or less) static reachability graphs, telling you if your code is somehow called from a certain point. With a dynamic language like Ruby even this is rather hard to achieve, as static analysis doesn't bring much insight in the face of meta-programming or dynamic calls that are heavily used in a rails context. So some tools actually run your code or try to get insight from test coverage. But there is definitely no magic spell.
因此，鉴于Rails应用程序的内部（主要是隐藏的）高度复杂性，您将无法通过手。最好的建议可能是尝试模块化您的应用程序，然后关闭某些模块以测试未使用的模块。可以通过适当的集成测试来支持。
So given the high internal (mostly hidden) complexity of a rails application, you will not get around to do most of the analysis by hand. The best advice would probably be to try to modularize your app and turn off certain modules to test f they are not used. This can be supported by proper integration tests.