RebelLabs的Java生产力报告仅关注性能

RebelLabs的年度《 开发人员生产力报告》已经发布，并将焦点直接放在Java性能上。 在从1500多个参与者那里收集了数据之后，该报告定义了性能团队和应用程序的一些关键特征，发现问题的常见原因是应用程序代码效率低下和数据库查询过多。

在ZeroTurnaround的赞助下，受访者回答的问题集中在应用程序复杂性，团队规模，应用程序性能分析和性能监控。 它还集中于开发人员用于性能目的的工具和流程。

在工具方面，VisualVM在应用程序性能分析方面名列前茅，得分为46.5％。 JProfiler以25.7％位居第二，其内部定制工具位居前三名（20.6％）。 ZeroTurnaround的XRebel占据了调查结果的3.3％。

在问自己一个高性能软件组织是什么样子时，ZeroTurnaround的报告作者和开发人员倡导者Simon Maple将那些声称其用户不受性能问题影响的受访者的活动进行了比较。 该报告得出结论，最终用户最满意的团队具有以下特征：

• 在较小的团队中工作。 问题最少的表现最好的团队成员减少30％。
• 早点测试。 用户满意的快乐团队在编写代码时进行性能测试的可能性提高了36％。
• 更有效，更主动。 这些团队在诊断，修复和测试性能问题方面的速度提高了38％。 每天或每周增加40％的可能性； 并且在出现问题时进行测试的可能性降低了20％。

JAXenter有机会就报告的结果采访了西蒙·枫。

JAXenter：今年的Java年度生产力报告仅关注Java性能，您将其称为“软件开发的黑手艺”。 这种关注的动机是什么？

Simon Maple：每年我们都会进行一次广泛的调查，以了解开发人员如何工作的技术前景，以及针对特定学科或软件开发领域的特定调查。 在ZeroTurnaround，我们最近才使用XRebel进入性能市场，该产品仅使用了一年多一点，因此在过去几年中，我们对性能的兴趣已大大提高。 我们注意到它仍然是应用程序周期中可以被抛弃或完全忽略的一个领域，因此我们想更深入地了解开发人员和团队当前如何看待性能测试以及他们如何进行测试。

该报告显示，负责解决性能问题的团队是Development，拥有94％的巨大股份。 您说在开发代码时对代码进行性能测试很有意义–高百分比表明这没有发生吗？

数据显示，在94％的受访者中，发现问题后由开发人员解决。 这并不意味着开发人员甚至在开发过程中都可以找到它们。 这使我们了解到，质量保证团队，运营团队或性能团队在周期中的任何地方发现与性能相关的问题时，往往会回到开发团队以获取修复。 功能开发可能需要几天，几周甚至几个月的时间。

实际上，其他开发人员可能在错误的情况下构建或重用了代码，这意味着潜在的修复可能已经处于混乱状态。 各种原因（如所描述的所有原因）都导致该修复程序变得更加昂贵，最终最终，实际上是由同一人实际制作了此修复程序，而不管是谁发现了何时发现该错误。

受访者用于应用程序配置文件分析的工具会让您感到惊讶吗？ XRebel的3.3％的结果呢？

我们希望JProfiler脱颖而出，尤其是我希望Java Mission Control的百分比更高，这不仅是因为它是一个很棒的工具，而且还因为它是免费开发的，并且随Oracle Java版本7u40一起提供。 XRebel的收益为3.3％，这对于一年前才投放市场的工具来说是非常高的。 尽管我很乐意认为此统计信息是准确的，但每次调查总是会有偏差，我希望这会对这里产生影响。 我们尽可能广泛地分享了该调查，甚至要求业内有影响力的人来帮助我们。 我们的社交媒体覆盖范围将包括我们的许多JRebel和XRebel客户，因此在查看结果时必须考虑到这一点。

当查看受访者对最常见的绩效问题的React时，您指出“我们作为一个行业未能正确测试”。 您认为解决测试的正确方法是什么？

虽然我的意思是说该声明是针对性能测试的，但实际上它实际上适用于所有测试。 有些人确实编写了出色的单元测试，并在CI环境中定期运行它们，但许多人仍然没有。 具体地说，在性能测试领域，我们需要改变思维方式，类似于一段时间前进行单元测试和功能测试的方式。

这种新的思维方式需要将性能测试归类为一等公民，并且应该定期进行早期测试。 一旦离开测试阶段，它通常被视为是一项可以做的最好的活动，或者被完全遗忘了，这只会给我们的客户带来糟糕的用户体验。 开发人员通常专注于他们的代码，而不是质量，这并不总是他们的错。 计划的严格时间表和压力很大，这是代码交付时未进行全面功能或性能测试的绝佳借口。 应用程序和代码只能与它们的测试（包括单元测试，功能测试和性能测试）一样好。 所有这三个都需要向左移，并在可能的情况下通过代码开发来执行。

您已经问过一个问题，即敬业的绩效团队是否更好，其结果倾向于他们在发现问题和错误方面表现出色。 您还有其他变量可以用来衡量此结果吗？ 那专业的表演知识呢？

真的很难回答这个问题，因为每个团队都不一样，而且知识水平不同的人也会产生巨大的影响。 另外，我们没有深入探讨的一件事是每个团队发现的错误的类型。 我推测，专用的性能测试团队将比开发人员运行更复杂的测试方案。 我不是因为他们有更多的时间，而是因为有一个专门的职位，我希望他们拥有更多有关性能领域的专业知识和主题知识。

我想说性能团队发现的错误不仅很难发现，而且更难以修复，这可以解释为什么修复这些错误所花的时间如此之多。 真实的经验和知识是理解这些团队如何工作的关键方面，但这是一个非常客观且难以衡量的指标。

完整的报告可以从RebelLabs 此处下载。

翻译自: https://jaxenter.com/rebellabs-java-productivity-report-119224.html