如何避免死于千刀万剐，或者说如何思考软件质量（2023）

# 如何避免千刀万剐式的死亡？或者，如何思考软件质量。 来源：https://www.evalapply.org/posts/how-to-not-die-by-a-thousand-cuts/index.html 如何避免千刀万剐式的死亡\. 或者，如何思考软件质量\. \↓[toc (https://www.evalapply.org/posts/how-to-not-die-by-a-thousand-cuts/index.html#blog-post-toc)\]发布时间：2022\-01\-20更新日期：2023\-03\-10 这不是一篇厚重的、长达300页的关于摩托车维修的禅宗对话。只是一篇漫谈式的博客文章，在其中思考软件产品的/质量/。 --- **目录**软件产品的本质是什么？ (https://www.evalapply.org/posts/how-to-not-die-by-a-thousand-cuts/index.html#what-is-the-nature-of-software-products)谁应对软件质量保证负责？ (https://www.evalapply.org/posts/how-to-not-die-by-a-thousand-cuts/index.html#whom-to-hold-responsible-for-software-quality-assurance)为什么？ (https://www.evalapply.org/posts/how-to-not-die-by-a-thousand-cuts/index.html#why)不同类型的产品有何不同？ (https://www.evalapply.org/posts/how-to-not-die-by-a-thousand-cuts/index.html#is-it-different-for-different-kinds-of-products)如何毁掉质量？ (https://www.evalapply.org/posts/how-to-not-die-by-a-thousand-cuts/index.html#how-to-destroy-quality)如何创造质量？ (https://www.evalapply.org/posts/how-to-not-die-by-a-thousand-cuts/index.html#how-to-create-quality)第一项技能是学会建设性地承受痛苦。 (https://www.evalapply.org/posts/how-to-not-die-by-a-thousand-cuts/index.html#the-first-skill-is-to-learn-to-suffer-constructively.)免责声明、我的过错等。 (https://www.evalapply.org/posts/how-to-not-die-by-a-thousand-cuts/index.html#caveats-mea-culpa-etc.) --- 首先，什么才是质量？ 万物皆涌现、变化并消亡。我认为*质量*是对这一过程的体验。*好质量*的本质归结为优雅地执行过程，并让我们离开时比来时更好。 此外，涌现和变化的过程——即生存——也是消亡的过程。因此，要清晰地思考前者的质量，就必须清晰地思考后者的质量。最可悲的展现方式是一种缓慢而痛苦的退化，缺乏治愈、慰藉、意义或希望。也就是那句俗语：千刀万剐式的死亡。希望你永远不会目睹这样的逝去，哪怕只是远远地看到。 好吧，这画风突然阴暗了，如果不小心，我们就会写出长达300页的摩托车维修禅宗对话。所以，还是让我们专注于更小、更轻松——甚至可以说是令人愉快的任务：思考软件产品的质量。 以下内容并无新意，但我感觉这些信息*及其*背景值得重复，因为即便现在还不明显，软件也总在让我们失望。而且常常带来可怕的后果。 ## 软件产品的本质是什么？ 看吧？这比问“生命的本质是什么”容易多了。 与其他任何机器一样，软件产品是由许多头脑和双手的劳动锻造而成，并且在其整个生命周期中都需要维护和保养。 与*所有*其他机器不同，它是纯粹的概念，因此具有无限的可塑性和可变性。而它也确实在不断变异。 有时，“完成”的软件会浮现，只需要小的修复和补丁，但其用途、界面和行为保持不变。许多 Unix 工具就属于这一类。有些项目（如 ZeroMQ）明确以此为目标。许多 Clojure 程序员珍视这种“完成性”。这样的例子零星分布。 大多数软件没有这种奢侈。大多数软件必须无限期地改变，因为它必须服务的世界也在无限期地改变。Emacs 编辑器是一个软件产品，自 1976 年诞生以来，它已经持续进化了*近半个世纪*，并且仍在蓬勃发展。这篇博文就是用 Emacs 写的。 还存在一个强大的正反馈循环。软件迅速改变世界，迫使软件更快地改变。当前机器学习和 AI 的重生可以被视为这一过程的表现。我们基本上是在说，一切加速得太快了，以至于人类已经*不可能*足够快地编写和修改软件，无法在 OODA 循环中跟上变化的步伐。因此，我们必须找到能感知世界的算法，然后动态生成或修改其他算法，以实现系统目标（即进一步改变世界，使之对我们有利）。 我们不禁要问：在这种持续不断、时而剧烈的变化压力下，我们如何确保产品继续蓬勃发展并取得成功？谁又应该为此承担责任？ ## 谁应对软件质量保证负责？ 常见嫌疑人？ - 那些“质量保证”专家？开发者？用户体验人员？DevOps 人员？ 不太常见的嫌疑人？ - 产品经理？分析师？客户成功？销售？市场？ - CEO？ - AI？ 考虑以下场景。所有这些都直接影响客户，让他们觉得“质量差”。思考一下，谁对根本问题（或更可能是多个问题）负责？ - 你的应用框架性能极佳且无故障。你的应用却崩溃了。 - 某个功能完全按承诺运行，但人们就是不会正确使用。 - 你的公司投入一半资源，以创纪录的速度交付第二个产品，但客户从未真正想要它。 - 一次重大更新在“不成功便成仁”的基础上推送了。自然它表现异常，无法回滚，修复成本是发布时的 5 倍，而返工会让你的世界征服计划再推迟数月。 - 你的服务无法扩展。你发现根本没有基准测试。 - 一次部署搞崩了生产环境。你发现是配置错误。 - 某个功能将数据泄露给非预期用户，违反了 SLA/法规。你的 CEO 发表声明，指责一名 DevOps 工程师。 - 持续数小时的故障无人监控，导致严重的广泛数据损坏。 - 你的生产环境经常明显降级。你的吉祥物是一只大型海洋哺乳动物。 - 你的生产环境很少降级，但一旦降级，就会连带拖垮半个已知互联网。 - 等等等等…… 在安静的自我反思时刻，你可能会对着镜子承认，千刀万剐的比喻是成立的。上述任何一个场景都可能是多次妥协的结果，这些妥协在当时往往肉眼几不可见。这些妥协不断累积——不，是*复利式增长*——随着时间的推移；先是创可贴，然后是缝合线，再是石膏，然后突然变成坏疽。也许整个系统就因此而死，或者半死不活地苟延残喘，直到有人下决心拔掉电源（或提供救助）。 你甚至可能承认，也许，只是*也许*，保证产品质量的工作属于*参与产品生命周期的每一个职能*。 ## 为什么？ 假设我们建模一个传统的软件生产工作流，即：分析 \-\> 产品需求 \-\> 用户体验/设计 \-\> 开发 \-\> “质量保证” \-\> 生产环境。 这种严格线性的模型在软件行业普遍存在。以下是从时间、复杂性、成本和风险角度体现的结果。 `` ^ 反馈 分析 -> 产品 -> UX/设计 -> 开发 -> "QA" -> 生产 --./--> 反馈 / 来得太晚 /- /- /- ^ /-- | 修复错误和 /-- | 妥协的代价 /--- ^ | /--- | | /---- ^ | | ~ 和/或 ~ /---- | | | 软件债务的 /------ ^ | | | 复利增长 /-------- | | | | ---------- ^ | | | | ~ 和/或 ~ ^ | | | | | 出错概率 | | | | | | 不断增加 ---+--------------+------------+----------+-------+-----+----------------> 时间、复杂性、沉没成本 `` 这样可视化一个线性工作流，暗示了几点： - 所有风险实际上都前置在分析阶段。如果这步错了，那么一切就都错了。 - 工作流看起来是线性的，但却有复利增长的债务/风险曲线。 - 通过将“保证”产品质量的任务分配给单个团队，我们最大化了自己过晚、错误地发现问题的概率，也完全可能发现不了坏消息。 图中不明显的是，风险根植于*反馈延迟*。交付压力大时，微弱信号就会死亡。 如果我们严格遵循上述线性工作流，我们的千刀万剐式死亡风险曲线将是一样的。无论我们是缓慢地以大批量在数月内完成，还是更快地以较小批量在数天内完成，结果都相同。小批量线性化甚至可能恶化总体风险曲线，例如当市场反馈循环延迟或非连续时。批次越小，越可能现在才收到几个批次前的反馈。这种延迟反馈往往会严重破坏严格线性流。 上图也不完整。要讲述完整的图景，我们需要深入讨论系统（这是另一个长话题，改日再谈）。我们可以通过场景分析做个小起步。考虑产品谱系上的关键点、毁掉/创造质量的方式，以及什么能帮助我们从中等走向更好？ ## 不同类型的产品有何不同？ 假设我们对比由主要客户定义的产品谱系中的两个典型端点。哪一个面临千刀万剐式的死亡风险？ 特征企业级产品消费级产品关键增长指标收入增长用户增长核心销售驱动力推荐 + 高管信誉推荐 + 亲友体验客户风险每个账户的高风险/回报微小的单位经济学合同风险带有严苛惩罚的 SLA1 份用户不读的 EULA/ToS等等.........事实是，不仅所有软件都会变异，我们*还*会对生产它的*组织*进行各种深层手术。整个系统——产品和组织——*同时*被弯曲、重构，甚至原地完全重新设计，其速度在其他行业非常罕见。为什么？因为软件本质上就是人们的思想在反复播放。 所以，无论我们如何分解，共同主题就是如此。每次热修复都是一道伤口。每次投诉都是一道伤口。每次应用崩溃都是一道伤口。每次服务中断都是一道伤口。等等。每道伤口愈合缓慢，并破坏质量和价值（估值）。 ## 如何毁掉质量？ 想出毁掉质量的方法很有用，这样我们可以与创造质量的方法进行对比。在职场生涯中，我见过和听过以下所有情况（希望自己没有主动实施过，但记忆这东西靠不住）。 - 曲解和错误地将软件测试贴上质量保证的标签。测试*不是*“质量保证”。 - 表面上让所有团队对自己的“QA”负责，实际上让经验最少的人日复一日地做这件事。 - 创造一种文化，让人们习以为常地说这样的话)： - “嘿，我把这个加到冲刺里了。一个小东西，我们别延误截止日期。” - “测试很无聊。” - “如果客户抱怨我们再修。” - “这他妈谁写的代码？” - “啊，是的，那些是已知的不稳定测试。重新触发构建就行。” - “你不懂你的工作。给我发货。” （这句很刺耳。喝啤酒/咖啡时再聊 :)） - 确保设计师、开发者和测试人员按照别人设定的任务和优先级工作。 - 确保有人因错误而背锅。 - 设置激励措施，让部门之间相互竞争。 - 聘请一位 Vogon 或 Darth Vader 式的 CEO。 - 进一步*正常化各种偏差 (https://danluu.com/wat/)*。 这只是我在写这篇博文时回忆起的一小部分。尽可能多地想出办法。#小技巧：从中情局现已解密的《简单破坏行动手册》(https://www.gutenberg.org/files/26184/page-images/26184-images.pdf) 中寻找灵感。特别注意第 11 部分：*对组织和生产的一般性干扰*。 ## 如何创造质量？ 一个线索是*不要*做那些毁掉质量的事情。另一个是做毁掉质量的事情的*反向操作*（例如分享知识而不是囤积知识）。第三个是观察高质量产品产出的组织是否有共同特征（它们确实有）。或许最重要的是要理解，没有获得这些特征的公式。 要设计和构建高质量的软件产品，设计和构建高质量的全组织系统和文化是必不可少的。我们有许多工具、框架和基本思想可供使用。但没有“最佳实践”流程或方法，也没有“一个奇怪的技巧”式的干预能修复破碎的系统和破碎的人。 “道路”必须共同演化： - 通过协作者的利益相关者， - 散布在整个组织中， - 适应组织独特的语境， - 与客户、合作伙伴和直接生态系统一起。 这普遍是一个非常困难的过程，其挑战惊人地类似于在懈怠一年后恢复健康所需的努力。它需要心态、领导力以及持续的、整体的、智能的*评估/应用*行为。而所有这些都源于*视角*。 > “视角值 80 个智商点。” —— Alan Kay 所以，如果我们要规划一条从更差质量到更好质量的路线，那么我们的首要职责就是主动让自己非常不舒服，去寻找对我们来说新颖的、多样化的、挑战现状的视角。并且…… ## 第一项技能是学会建设性地承受痛苦。 我们在受苦，你和我。 这是不可避免的。然而，这也是生命蓬勃发展的原因。*“我们为什么受苦？”* 这是一个值得讨论的好问题，因为建设性的痛苦能带来高质量的结果。 好了，回到现实世界…… 在懈怠一年后恢复*以前*的健康高峰，这条路充满了肌肉酸痛、对着闹钟咒骂、太多天变成易怒暴躁的人，以及持续与沉迷于美味易得的即时满足感作精神斗争。在变得容易之前，它先变得更难。然后我们到达之前 S 曲线的顶端。然后我们必须再次开始循环，攀登下一个 S 曲线。 我们非常幸运。 同行者们一直在我们周围培育能够产生质量的对话和变革。我们可以接触到不断增长的顶尖行业研究*和*经验报告。毫不夸张地说，其中许多教训是用眼泪、鲜血和生命换来的。让我们用这些强力工具来增强我们的直觉。那些来之不易的*80 个额外智商点* 正等着我们去拿。 一些精选资源。 许多输入塑造了我对质量的思考（好吧，是所有事物，因为一切都有联系）；包括人、事件、书籍、讲座等。如果你想知道从何入手。这些不是处方，而是一种样品拼盘。触发你自己的搜索。请给我更多！ 系统： - 《系统思考》(https://www.chelseagreen.com/product/thinking-in-systems/) 是一个很好的入门书。 软件复杂性： - 《走出焦油坑》(http://shaffner.us/cs/papers/tarpit.pdf) - 《没有银弹》(https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet.html) - 《复杂性的架构》(http://ecoplexity.org