Get best of the week

我们为什么要编写质量这么差的程序？


:
— , ,  — .
- :
— . .
:
— .
— ?
— . , .
— ?
— , , , , , .
-他们说可靠性是由称为区块链的技术来保证的。
-Ahhhhhhhh !!!无论他们说什么，都不要触摸它！深入挖掘。不要忘记手套！
资料来源：XKCD，Creative Commons 2.5许可证。

上周的移动计数应用程序出现故障，对爱荷华州民主党大会造成了严重破坏。全州会议开幕几小时后，很明显出现了问题。结果仍然未知。有消息描述技术问题和误解。爱荷华州民主党发表声明否认有关网络攻击的传闻，但确认了该移动应用程序的技术问题。

一周后，我们已经更好地了解了发生了什么。专门为此事件在爱荷华州编写了一个移动应用程序。它以beta版本分发，绕过了大型应用程序目录。用户受了苦，但是却难以使程序正常工作。安装后，她极有可能无法回复电话。在某些会议场所，没有互联网连接，这使在线应用程序变得无用。民主党有一个备用计划：像往常一样通过电话报告结果。但是电话线被在线巨魔所阻塞，这是出于lulz的原因。

Twitter跟随了#app和#problems标签的浪潮，软件工程师引用了KDPV。我也这样认为。这部动画片中的话很好地概括了正在发生的事情的一般感觉：“我不太知道如何表达它，但是我们的整个领域在我们所做的事情上都是糟糕的，如果您依靠我们，那么每个人都会丧命。”软件工程师不会直接说出来。但这听起来很相似。什么意思

这就是我们的意思：只要失败的后果无关紧要，我们就可以很好地开发软件。平均而言，程序足以以某种方式工作。但是，对于大多数程序中的错误，我们并不感到特别惊讶。这些并非罕见事件。软件工程中的许多常见实践都来自这样的假设，即崩溃是正常现象，最重要的是新功能。失败真的很便宜。如果最大的公司之一的在线服务在两个小时内完全断开连接，他们将在一周内忘掉它。这个假设体现在常见的口头禅中：“快速移动并破坏一切”（快速移动并破坏事物），“滚动并重复循环”（启动并重复）。

市场对这种“不负责任的”行为给予了慷慨的奖励。在许多网络公司中，每位用户的微薄利润乘以数百万（或数十亿！）用户。这对于拥有消费者应用程序或网站的公司是有益的。实施是昂贵的，但是成本是有限的，并且分发是几乎免费的。消费软件行业找到了一个折衷方案：我们正在降低实施速度，以使我们的缺陷水平适度降低，但不要过高。

我们将这种软件开发称为“网站的经济模型”：当实施的收益很高而重试的成本很低时，管理层则鼓励高速发布功能。这反映在项目管理及其实施的现代实践中，我将在下面进行讨论。

但是，正如我所说，“只要失败的后果无关紧要，我们就可以很好地开发软件。” 如果后果不菲，这种方法会导致严重的失败，就像在爱荷华州一样。软件开发的普遍做法已经从Internet的经济模型中发展出来，当违反了该模型的假设时，软件工程师的工作就很糟糕。

网路公司的程式设计如何运作？


假设假设的公司QwertyCo。这是一家面向消费者的软件公司，年收入1亿美元。我们可以通过与其他公司进行比较来估算QwertyCo的规模。 WordPress托管服务商WP Engine 在2018年实现了1亿美元的ARR。蓝色围裙全年收入6.67亿美元。因此，QwertyCo是一家中型公司。她拥有数十到数百名工程师，并且没有在公众发行中发行股票。

首先，请考虑QwertyCo的项目管理经济学。领导者了解到，您不想立即宣布一项新功能。您需要在软件质量，截止日期和实施速度之间折衷。

软件质量对他们来说有多重要？并不是的。如果QwertyCo网站一年不工作24小时，他们估计损失仅为273,972美元（假设正常运行时间与收入呈线性关系）。他们说该站点通常会离线15分钟，并且没有人真正在乎。如果该功能使站点崩溃，他们将回滚该站点并稍后重试。重复尝试很便宜。

新功能对QwertyCo有多重要？根据我的个人观察，一位工程师一个月的工作就能将优化站点的收入从-2％更改为1％。这是每个工程师每月可获得100万美元QwertyCo额外收入的机会。诸如A / B测试之类的方法甚至可以减轻错误：几周之内，您可以检测到负面或中性的变化并删除这些功能。不好的特性很便宜-它们在有限的时间内保持活动状态。胜利是永远的。即使很少的获胜赌注也会使QwertyCo获利。

考虑到利弊，QwertyCo应何时发布功能？经济计算表明，即使高风险功能有时会获利，也应启动。因此，每个项目都变成了一个优化游戏：“到这个日期可以实现多少？”，“实现整个项目需要多少时间？如果从中删除X怎么办？如果删除X和Y怎么办？如何加快某个部分的执行？”

现在从软件工程师的角度考虑一个软件项目。

他的主要资源是时间。安全的软件开发非常耗时。产品一旦达到一定的复杂性阈值，就会有几个开发阶段（即使它们没有作为明确过程的一部分通过）。应该在产品经理的帮助下进行规划。将产品转换为技术项目或计划，必要时将其划分为子任务。然后编写带有测试的代码，进行代码审查，记录统计数据，将产品与信息面板和警报集成在一起。如有必要，将执行手动测试。另外，编码通常具有称为重构的额外开销。：修改现有系统以促进新功能的实施。在“小”功能的实现中，编码本身仅需要10％到30％的时间。

开发人员如何浪费时间？最常见的是系统故障。在站点停机期间，一切都包含在工作中。最有经验的工程师停止正在进行的项目，以使站点恢复正常。但是扑灭大火所花费的时间就是他们没有给公司带来额外利益的时间。他们的项目落后于进度。如何减少停机时间？书面测试，监视，自动通知和手动测试都可以降低灾难性事件的风险。

工程师又如何浪费时间？通过更细微和罕见的错误。一些错误很少出现，但是会造成很大的损失。如果用户执行特定的操作序列，则可能会丢失数据。当工程师收到有关此类错误的报告时，他必须退出所有错误并进行修复。这分散了当前项目的注意力，并且这种停机时间会逐渐增加。

因此，经验丰富的软件工程师开始密切关注代码的质量，他们想仔细检查它。这就是工程组织使用乍一看会减慢开发速度的方法的原因：代码分析，持续集成，可观察性，监视等。如果尽早发现错误，它们的成本会降低，因此工程师会在早期错误检测方面进行大量投资。他们还专注于重构，从而简化了实现。在更简单的实现中，出错的机会更少。

因此，管理和发展在质量上有相反的观点。本手册同意较高的错误率（但不要过高），工程师希望该错误为绝对最小值。

这如何影响项目管理？经理和开发人员将项目划分为小任务。项目准备时间取决于任务数量和工程师数量。通常，一个项目花费太多时间-并且通过删除功能对其进行调整。然后工程师执行任务。任务的实现通常在sprint内部执行。。如果冲刺时间为两周，则每个任务都有一个隐含的两周计时器。但是，作业通常比您想象的要花费更长的时间。工程师会做出艰难的优先级决策，以按时完成：“如果我编写基本测试，并且错过了原计划的重构，我可以在冲刺结束时做到这一点。”冲刺施加恒定的压力，推动显影剂。这意味着工程师可以降低质量，也可以在下次会议上承认失败。

有人会说我对冲刺太苛刻，他们是对的。实际上，所有这些都是由于时间的压力。冲刺过程是通过多次施加压力来增加这种压力的便捷方法：一次是在评估整个项目期间，另一次是针对每个任务。如果产品按公司的附加值计价，则实施时间会自行调整。工程师对快速实施也很感兴趣，但是从长远来看，而不是短期内，工程师通常会尝试优化成本。但是，许多组织通常仅在短期内刺激当前的速度。

建立了这样的激励机制后，经理可以得到他想要的东西：他可以命名职能和未来的日期，而管理层和开发人员将讨论如何做到这一点。“我希望您在两个月内一键式购买，而无需创建帐户。” 经理和开发人员将把所有任务写完两周，并将缩短清单，直到他们启动名为“一键购买”的功能。她将有中等程度的失败风险，并且可能仅在几次迭代后才能工作。但是故障是暂时的，功能是永远的。

如果违反了这种经济模型的假设，会发生什么？


正如我所说，只要失败的后果无关紧要，我们就可以很好地开发软件。标语为“快速移动并破坏所有内容”，“滚动并重复”。但是每个人都可以想象这样一种情况，即翻新成本很高甚至根本不可能。在紧要关头，倒塌的建筑物可能会杀死数千人，并造成数十亿美元的损失。 2020年爱荷华州派系国会就是一个比较温和的例子。如果活动失败，晚上所有人都会活着回家。但是该党不能第二次组织这些会议……不花费大量时间，金钱和精力。

简要说明：在本节中，我将“高风险”一词用作“无法重试的情况”和“重试可能性高的情况”的缩写。

在高风险情况下应用经济站点模型时会发生什么？让我们随机举一个例子：假设您正在编写一个应用程序，以报告在爱荷华州的会议结果。您将采取什么步骤来编写，测试和测试应用程序？

首先，工程物流：您必须同时编写Android应用程序和iPhone应用程序。报告是中心要求，因此需要服务器。混乱的收集规则必须同时在客户端和服务器上进行编码。系统应将结果报告给最终用户；这是另一个需要编程的接口。民主党可能具有应写入应用程序的验证和报告要求。此外，如果服务器在会议期间出现故障，将是非常不合适的，因此您需要实施某种监视系统。

接下来，如何检查应用程序？一种选择是用户测试。您向潜在的用户显示了一个虚拟应用程序的图片，并提出了诸如“您认为此屏幕有什么作用”之类的问题。和“如果要使用$ a_thing，您将在哪里单击？”设计总是需要进行多次迭代，因此经过几轮此类测试后，可以期望获得高质量。大型公司在引入重要功能之前通常会花费几轮。有时，他们甚至在至少编写一行代码之前就收到反馈后就取消了功能。用户测试很便宜。是否很难找到五个愿意花15分钟在问卷上的人，他们收到了一张五美元的礼品卡作为礼物？在我们的情况下，最困难的事情是制作一个具有代表性的样本，与爱荷华州的民主代表相对应。

然后，您需要检查运行中的应用程序：在智能手机上安装并配置它。民主党必须了解如何取得成果。如果发生故障，则需要备份计划。一个好的测试可能包括一个“试验会议”，在该试验中，爱荷华州民主党的几名成员下载了该应用程序，并在给定日期将结果报告给中央服务器。这将发现问题并概述总体情况。引入产品的各个部分时，可以分阶段进行验证。

此外，互联网上充满了恶棍。例如，俄罗斯团体广泛散布了错误信息通过Facebook，Reddit和Twitter等社交媒体。因此，您需要确保没有陌生人干预。如何检查结果的真实性？除了小人外，互联网上到处都是笑话者，他们准备好以娱乐为目的来破坏任何事件。我们的系统如何抵抗DDoS攻击？如果没有，是否有备份计划？谁负责通过在会议上进行报告来引入后备计划？如果会员帐户被黑怎么办？如果公司没有安全专家，则该应用程序可能应该接受独立审核。

此外，您如何保证软件中不会出现会导致结果失真的错误？因此，民主党应该对自己保持怀疑：如果在其队伍中存在叛徒，是否有可能相信结果？结果应可用于使用纸质副本进行验证。

好吧，让我们停止列出问题。一件事很清楚：确保一切正常需要花费大量时间和资源。

爱荷华州核心应用程序的创造者获得了60,000美元和两个月的收入。他们有四个程序员。这笔钱不足以支付四个优秀的程序员和其他费用。金钱不能交换时间。几乎没有外部帮助。

想象一下，您正在使用公认的做法，即从时间表中删除项目中的任务。您将尽力节省时间。应用程序目录的预览通常花费不到一天的时间，但是在最坏的情况下，它可以持续一周，并且该应用程序可能会被拒绝。因此，我们跳过这一点：民主党成员将通过Beta链接下载该应用程序。即使进行了免费的安全检查，也要花费很长时间才能满足他们的所有建议。因此，我们拒绝安全检查。也许在后端的开发过程中，您支付了设计师1000美元用于创建应用程序和徽标的布局。您计划进行一轮用户测试（但是在截止日期到来时跳过它）。快速推出并重复循环！一切都可以固定。

而且编程总是花费比预期更长的时间！您将遇到插头。首先，召开会议的规则并不完全清楚。当将数字解决方案应用于模拟世界时，总会发现这一点。现实世界可能会产生歧义和不一致，但数字世界不会。针对您的问题，民主党委员会将进行澄清。这会让你退缩。委员会还可以在最后一秒钟更改规则。这将导致您在截止日期之前更改应用程序。接下来，您有几个开发人员，这意味着协调开销。每个编码器是否100％精通移动设备，和服务器开发？他们都完美地掌握了React Native吗？姐姐打字稿？客户服务器通信？您选择了哪些框架和库？每个“否”都会增加开发时间，以考虑协调和培训。每个人都对您使用的测试框架感到满意吗？开玩笑。那里有什么测试...是的，起初他们编写了一些测试，但是应用程序变化如此之快，以至于被删除。

时间不等。两个月已到期-您将用最后的努力到达终点，并发布最终版本。

根据网站的经济模型，匆忙完成是好的。最后，匆忙并不重要，因为您越过终点线！所有问题都可以在几周内解决，然后继续进行下一个项目。

但是，在美国爱荷华州民主党大会上反映了这一仓促。在活动过程中，开始出现电话投诉。理论上不可能的结果或重复开始出现。不久，有趣的程序员高兴地发布了KDPV的图片，并说爱荷华州的派系国会根本不应该下令申请，而投票只能由纸技术来信任。

发现


这篇文章可以帮助我个人得出以下结论：在计划项目时，有必要正式确定变更成本。我过去曾凭直觉进行过此操作，但应具体具体化。这种形式化有助于了解在任何情况下都不能失败的任务。就像在我的移动机器人中一样：实施周期长，故障所造成的损害可能会蔓延到屋顶。我们花了很多时间来开发监视并创建抑制和停止失控系统的可靠方法。我也从事消费者Web服务已经十年了，失败的后果更低。人们更愿意承担短期债务，并有暂时失败的风险，尤其是在回滚便宜且数据丢失不太可能发生的情况下。至少，刺激正在推动这种行为。我们行业中有特殊的技术可以防止此类问题。其中之一-虚构故障调查（验尸）。您需要更频繁地执行此操作。

爱荷华州的失败有积极的结果。一些与IT无关的人意识到程序中存在错误。在未来几年中，政党申请开发的发起者将开始问：“什么保证了爱荷华州小议会的情况不会重演？”也许他们会熟悉文献，这是在教管理人员如何与工程师一起工作。例如，美国国防部有一个名为“如何识别敏捷伪造项目”的指南，其中描述了有关合同的可疑迹象。面向初创企业的论坛到处都是非技术人员，他们询问（并获得）有关雇用开发人员的建议。

IT行业没有学到任何东西。爱荷华州派系大会提供了一个机会来研究“错误的高成本”的假设将如何改变我们的核心流程。但是我们没有抓住这个机会，也没有从中提取任何东西。消费软件行业并不关注错误的风险。实际上，我们甚至对错误感到满意。如果外界对在某些领域提高我们的代码质量感兴趣，那么他们应该对这些领域进行规范。这将不是第一次。萨班斯法律（Sarbanes Law）-Oxley和HIPAA是网站经济模型开发中的监管示例。监管还不够，但是可能有必要。

这就是我们说的意思：“我不太知道如何表达它，但是我们的整个工作领域都很糟糕，如果您依靠我们，那么每个人都会丧命。” 我们的行业是在挫折便宜的环境中形成的。我们对快速发展感兴趣。如果更改不可能或太昂贵，那么我们的常规流程将无法正常工作。

More articles:


All Articles