我有一个在生产中运行的基于java web的应用程序。我需要一些方法来通过最终用户的操作来查看实际使用的代码的所有部分。
进一步澄清我的要求。
我不想放置基于日志的解决方案。任何需要我放置一些日志并分析日志的解决方案都不是我所期待的。
我需要一些适用于类似测试覆盖率报告器等类似行的解决方案。像cobertura或emma报告一样，在运行单元测试之后，它会向我显示我的代码的所有部分都是由单元测试激发的。我需要能够在生产中监听JVM并告诉我哪些代码的所有部分都是由最终用户的操作在生产中启动的东西。
为什么我要这样做？ 我有一个我继承的代码。这是一个很大的部分 - 大约25,000个课程。我需要做的一件事就是切掉那些没有被过多使用的应用程序部分。如果我可以向管理层证明应用程序的某些部分几乎没有被使用，我可以从这个产品中删除这些部分并有效地使这个产品更易于管理（如需要运行每个的手动回归测试套件）一个星期左右，需要几天，可以缩短）。
希望有一些现成的解决方案。
答案 0 :(得分：3)
正如Joachim Sauer在下面的评论中所说的那样：最直接的方法是使用代码覆盖工具，用于单元测试并使用它来检测生产代码。
有一个主要问题：开销。代码覆盖率分析确实可以减慢速度，而知情的用户群可以容忍一些临时性能下降，整个事情需要保持可用。
根据我的经验，JaCoCo相对较轻，不会产生太大的开销，而Cobertura会强加巨大的减速。另一方面，JaCoCo只是标记“命中或没有命中”，而Cobertura给你每线命中数。这意味着JaCoCo只会让你找到死角，而Cobertura会让你找到很少发现的点。
无论您使用这两种工具中的哪一种（可能是一个接一个），您最终都可能会使用巨型类白名单和类黑名单来限制覆盖计数到有意义的地方，从而降低性能开销。例如，如果整个事物都有一个前端控制器Servlet，包括分析中的那个将最大化性能开销，同时不提供任何有价值的信息。这可能会转化为大量的工作和大量的应用程序部署。
实际上，识别特定子系统的瓶颈/网关并在每个子系统上打一个计数器（例如perf4j甚至是完整的Nagios）可能会更快，更少工作。查询是打击计数器的另一个好地方。如果您怀疑应用程序的某些部分很少使用，请在那里放几个计数器，看看会发生什么。