开发团队如何防止消费者应用程序的性能下降？

当我之前询问造成缓慢软件的原因是什么时，我收到的一些答案表明这是一个社会和管理问题：

这不是技术问题，而是市场营销和管理问题。...最好，产品经理负责编写用户应获取的规格。许多事情可能会出错：产品经理无法在规范中添加按钮响应...质量检查人员会根据该规范进行中等程度的测试...如果产品管理人员和质量检查人员都睡着了，我们程序员无法弥补这一点。- 鲍勃·墨菲

人们使用大型应用程序工作。当它们起作用时，就像漏洞一样，性能问题会逐渐蔓延。区别在于-错误是“不好的”-他们大喊“发现我并修复我”。性能问题只会摆在那儿，并且变得更糟。程序员经常认为“好吧，我的代码不会出现性能问题。相反，管理层需要给我买一台更新/更大/更快的机器。” 事实是，如果开发人员定期只是寻找性能问题（这实际上很容易），他们可以简单地将其清除。— Mike Dunlavey

因此，如果这是一个社会问题，那么组织可以采用哪些社会机制来避免将缓慢的软件交付给客户？

有了正确编写和完整的要求，就不会在错误和性能不佳之间进行区分。因为您将性能指定为非功能性要求，所以性能差会像其他任何错误一样成为错误，并且会在发布之前被质量检查人员捕获并由开发人员解决。

有社会问题吗？我不这么认为。主要问题是要求不完整。作为自由职业者工作了多年，我从未见过一个非功能性要求，即一个特定任务平均必须在最多N秒内执行。如果经理/客户/利益相关者或任何人不关心绩效资产，为什么我（作为开发人员）会对此烦恼，因为必须关心它的人根本不在乎？

还有一个影响性能不佳的因素：开发人员在性能良好的昂贵PC上工作。当您在具有8 GB RAM，高端SSD，最新OS等的四核PC上工作多年时，很难想象您的应用程序将如何在双核PC上的Windows XP上运行。配备512 Mo的RAM和90％的旧硬盘，并且多年未进行碎片整理。不幸的是，在某些国家/地区，最后一种情况是我们为大多数应用程序消费者看到的情况。开发人员PC与消费类PC之间的差距越大，开发人员要注意其应用程序的性能就越复杂。

问题（？）：

• 客户（或最终用户）没有抱怨（足够）
• 因此，项目（/产品）经理不认为这是一项要求
• 因此，开发人员没有时间修复它。

您必须从头开始，对客户进行教育。但是，如果他们购买iPhone而不是购买速度更快，光泽度较低的手机，则开发人员应该将时间花在外观上而不是性能上。组织不是问题。

当然，无论如何，有些事情会有所帮助。等待自动化测试很烦人，因此，如果您进行了自动化测试，则开发人员会不断收到有关性能问题的反馈，他们将更有可能解决该问题（作为技术问题，而不是功能）。

但是你不能做任何事情。它可以优化或添加功能，花钱的人可以决定。

但是有一些好消息：我注意到SaaS / Cloud / Buzzword应用程序在这里有很大帮助。当人们在几个类似的Web应用程序之间进行选择并开始实时测试时，而不是首先创建人为的“必需”功能列表时，他们会更快地受到响应的影响，因此性能将得到更多关注。

可悲的是，我发现最大的问题是你不能做任何事情。您有发货日期，并且知道它很慢，但是需要将功能X，Y，Z投放市场。

在您看来，速度较慢，您以后可以修复，但该应用程序至少可以运行。

因此，您担心功能性和美观性（因为用户经常关注美观性）。下一个版本将修复性能。

但是PM只是为您提供功能列表，而没有时间来修复性能。

恶性循环还在继续。

我同意其他人的看法，我们应该找到方法使开发人员更加关注该问题，例如使他们在较慢的硬件上进行测试以及确定性能目标。没关系，但是实际上，在性能调整方面，

人们会知道-他们不知道

他们可能会认为确实如此，但是只需在StackOverFlow和此论坛上浏览所有与性能相关的问题和答案即可。令人痛苦的是，有多少人对性能几乎没有常识。

这不是只是说说，人们需要通过学习做它。他们唯一处于这种模式的时间是当他们上课，从书本或博客中学习新事物时。

因此，我能想到的解决该问题的唯一方法就是让那些教编程的人，并教他们如何做。

天知道，我已经尝试过这些论坛，例如-

• 基本的超简单方法
• 43倍加速-做 的是与你的分析器
• 令人作呕的原因的细节

任何人都可以做到。他们只需要实际执行即可。

使性能成为要求。

编写高性能代码很困难。它需要扎实的概念，例如线程，异步事件处理，缓存和渐近复杂性。从与我合作过的一组程序员的判断来看，任何给定组中的大约20％至40％的人对这些概念的理解都不足够，无法将性能考虑因素自然地纳入他们的日常工作中。

但是，这些程序员显然仍然对公司有用，但是它们被分配给对性能不重要的任务，因此您最终得到了可以在不丢失任何帧的情况下完美播放Netflix流的蓝光播放器，但需要30-60秒打开显示队列的菜单项。

除非您是一家有实力的软件公司，有能力解雇20％的员工并将其替换为经验更丰富（且价格更高）的开发人员，否则，解决该问题的唯一真正方法是开发人员培训和提交错误报告。我不知道其他公司的情况如何，但是在这里，如果我们的开发人员看到性能问题，而我们没有时间或业务优先权来解决，则我们完全有权就此提交错误报告。可能需要几个发行才能达到积压的顶部，但通常最终会解决它们。

如果需要性能，请对其进行测试。

否则，沃利可以编写一个无限循环，并尽早离开“这需要一段时间”。他可以要求。

您的软件验收测试应针对各种操作性能特征进行详细的验收测试。

如果不这样做，就不会在产品中发挥任何性能。

性能（如资源消耗）应预算到子系统中。然后，子系统验收测试可以对其进行检查。

然后您可以及早测试性能。甚至单元测试也可以检查它。

因此，现在开发人员将其作为接受标准，并且可以组织其方法以适应它。

我现在工作的地方，性能压力测试比我们所知的任何客户数据集大2倍。它会定期破坏该产品的新版本。好的测试。

我记得90年代中期，我花了一些时间尝试优化某些东西，一位同事告诉我：“这是在奔腾上运行的，谁在乎呢？” ....令人大开眼界。可悲的是，这只是冰山一角，我听说过我整个职业生涯中的态度-尽管“奔腾”部分已经随着时间而改变。

使普通开发人员关心的唯一方法是缺乏性能，而将其视为客户方面的错误。根据应用程序和受众的不同，这可能是容易的任务，也可能是艰巨的任务（我已经看过两者）。如果听众不关心性能不佳，开发人员将永远不会（迅速，良好，快速-选择两个）。

但是，程序员不需要QA的来信就可以意识到按键和响应之间的3秒延迟是不可接受的

同意不应该。它所需要的不只是：证明获得的滞后与最终用户有关。

鉴于您未提供任何上下文，因此在dev / QA环境中出现延迟的可能性完全有可能是由于其本地问题导致的磁盘/内存/网络访问速度缓慢。如果是这样，您的质量检查人员和开发人员只会浪费他们的精力来修复对最终用户无关紧要的事情。

依靠开发人员进行性能测试的效率与掷骰子以选择加速功能的效率差不多。哦，它和它一样可靠-“开发人员通常对应用程序中的性能问题的实际位置有着可怕的直觉”（Brian Goetz）。

• 我去过一个项目，la脚的管理人员曾经决定他们聪明的营销人员和聪明的程序员足以应付客户的性能问题。这是一个很棒的教训。拒绝发布，半年的工作花在了垃圾箱上，公司几乎失去了战略合作伙伴。最后，他们邀请了专业人员（基准测试，统计，UX，低级优化等专家）和专业人员解决了这一问题。

所有程序员都应该进行自己的质量检查，以便他们立即看到此类问题吗？

事实证明这是可行的，并不意味着它就是要走的路。恰恰相反-以我的经验，这是降低程序员工作效率的最可靠方法之一。几乎和无休止的会议一样好，甚至比面试候选人还要好。

• 作为一名前测试人员，我曾经认为将开发和质量保证活动结合起来应该不是问题。看起来常规开发测试和系统质量检查之间的区别并不重要。我认为dev / qa分离只是软件行业的传统。学会了相当困难的方法，事实并非如此。事实证明，分离是关注焦点和生产力的问题，而且是相当严重的问题。

如果存在性能问题，请给我一个基准并设置目标性能，我会尽力实现这一目标。我在性能测试上不太出色，但对优化了解一两点。

我认为您会发现问题的99％是示波器的蔓延。以dvr为例。您可能认为这很容易，但随后TIVO或竞争对手推出了一项广受欢迎的新功能。接下来，您会知道一个新功能是在盘子上。它可能与现有产品兼容，也可能与现有产品不兼容，并且我们不会重做需要很长时间的现有产品。因此，该功能会被卡住，从而降低性能。当然，有数据可以获取信息，但是如果没有想到要获取这些信息，那么很有可能将很难获得它。因此，当您每次访问程序列表时，现在都有一个复杂的过程来构建该信息。

忽略似乎不在乎的开发人员...

我认为，通常，从事代码工作的开发人员通常没有连续测量性能的工具。

例如，如果可以测量您的应用程序的响应时间（例如，基于Web的应用程序或查询数据库等）-您当前是否收到通知（电子邮件，SMS等），表示最严重的“前10名”执行（或超过确定的阈值）响应？

在许多情况下-开发人员无法从“实际”部署中获取此信息，因此很容易忽略您看不到的信息。

但是，如果每天/几个小时收到一封电子邮件，指示屏幕“ x”需要13秒钟加载，并且正在运行以下SQL查询，则SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...您最好相信开发人员可以（并且希望会）完全解决问题它。

因此，尽管我想相信所有程序员都认真对待性能，但我认为对问题的缺乏了解通常是罪魁祸首。

注意：我认为这是开发人员都应该请求访问（甚至开发这样的功能）并且管理人员应该提供/资助这样的工具的事情。

您能否提出更好的示例，使我们真正将责任归咎于程序员？除了Eclipse外，还有一个评论者已经指出是由插件完成的（每个新Eclipse版本的我的第一次安装运行时都像闪电一样，但是当我添加其他工具时，它开始变慢），您的示例可能不是程序员，而是代码相关但环境相关。

孤立地在计算机上运行程序并确定其是“快速”还是“慢速”的日子已经一去不复返了。您提供的其他示例取决于它们的环境-当前的网络拥塞，后端服务器是否过载，网卡配置不正确，电缆是否有故障，在您附近使用它的其他人的数量或数百个其他变量。例如。我们的托管服务提供商向服务器千兆连接收取了额外费用，但最终我们确定所有连接都通过了具有10Mb端口的古老防火墙设备。这些问题四处转移，很难找到。

同意，程序员可以做很多事情（最小化带宽，UI技巧可以提高响应速度并显示进度以给人以快速的印象）。但是，当您进入现实世界时，会遇到各种各样的情况，您只能通过经验来学习（并且您会看到自己的假设在您面前崩溃）。

您愿意花多少钱购买更好的软件？市场将等待多少等待更好的软件？想要添加到下一个发行版中的工作量是多少？

这是一个残酷的市场，在那里做出了许多妥协。如果确实是废话，那么市场将（或应该）使产品不合格。也许有足够的客户可以维持现状？

我认为对这个问题的最一般的回答也是最难管理的，这是每个程序员都应该注意他们所做的任何事情的性能。我也意识到这有点麻烦。

根据项目的规模以及相应的团队，我相信拥有敬业的性能程序员可能会有很多价值。

例如，我曾在一个团队中工作，该团队的项目团队（包括大约30个开发人员）至少有2个人致力于性能优化。由于存在大量互操作性组件，不仅在Web服务上，而且在具有各种数据映射和适配器组件的传统层方面，该特定应用也很容易出现性能问题。

第一手经验很重要。给开发人员一台快速的计算机以进行编译和构建，但是要让一台运行速度非常慢的超负荷计算机（可能实际有一定比例的用户）在其上运行他们的应用程序。（这可以在基于云/服务器的开发环境中通过按功能对VM或服务器进行分区来完成。）给他们一部手机，电池电量已耗尽，并要求他们仅在最初的移动应用测试中使用它。

如果开发人员在性能和电池寿命方面对客户表示同情，那么他们不会将性能视为放在优先级列表底部的一些半伪造的管理规范。（例如：“嘿，我认为这是过早的优化”，直到为时已晚。）

停止购买这些东西，并在遇到的任何在线评论中评论效果不佳。

如果设备仍在销售，则该软件“足够好”，不会花费更多的时间和金钱。如果对性能的不良评价大大降低了销售量，则该软件“不够好”，需要修复。

消费品生产者唯一感兴趣的指标是单位销售和利润。

我同意应该在提高性能等方面更好地教程序员。

但是我认为该解决方案并不能为程序员提供几乎快要使用的硬件。如果您的视觉工作室每天崩溃两次，将产生多大的压力，生成内容所需的时间为x秒，打开解决方案所需的时间为y秒，更改窗口所需的时间为z秒。我认为这对公司来说不是很划算，因为硬件价格便宜，程序员的时间也很昂贵。

由于将由代码处理的下一手人员是QA（测试）团队，因此最好向他们传授性能的重要性，具有可接受的性能标准的标准等作为企业标准（在完美的世界中） ，性能标准应该符合规范，但是这种情况很少发生）？（即常规企业ee更改页面/标签应该立即发生，“保存更新应该在x秒内发生”，如果它是关键应用程序，那么...）。质量检查小组运行的计算机应该是典型的用户计算机。（我们不想给他们386来惹恼他们，但不要给它们提供8GB内存的四核）。如果他们对性能感到不满意，他们是否会向程序员发泄？

我认为客户/项目经理应强迫程序员/质量保证团队/开发人员/公司团队代表以他们拥有的最低典型硬件进行演示。（例如，公司中最弱的计算机）。如果要重写，他们将需要收集有关在旧软件中执行x处理的速度的数据，并将其与新软件中的处理速度进行比较（这可能会比较慢，因为新软件可能涉及额外的业务流程，但是应该有一个可接受的窗口）。

我之前已经说过，但是我会再说一遍：我认为处理此问题的最佳方法之一是让开发人员简单地（相对）地使用前沿硬件。

对于您的典型程序员而言，大多数正式的性能考虑仅是次要的：“当我尝试运行它时是否很烦人？” 如果他们觉得很烦，他们会（至少尝试）修复它。如果他们对它的运行方式感到满意，那么最好的选择就是半心半意地进行修复。这也有助于及早发现问题，然后再解决这些问题。

如果说质量保证必须强制执行规则，而开发人员由于认为性能足够而使开发人员真的不相信，那么很有可能您获得的大多数“修复”都将获得创造性的方式来解决规则，不是真正的修复程序，可以改善最终用户的生活。

同时，我要补充一点，我很少将其视为问题。如果有的话，我已经看到开发人员花了太多时间试图提高性能，而我真的没有那么多麻烦（我也常常为此感到内sin）。