如何避免软件在千刀万剐中消亡
How to Not Die by a Thousand Cuts. Or, How to Think About Software Quality
软件质量并非单一团队的职责，而是贯穿产品全生命周期的集体使命。文章指出，软件是纯粹的概念，具有无限的可塑性，必须随世界变化而不断演进。传统的线性工作流将风险前置，导致反馈延迟，最终让微小的妥协累积成致命的“千刀万剐”。从 Enterprise 产品到 Consumer 应用，无论是 ZeroMQ 还是 Emacs，所有软件都在经历持续的蜕变。真正的质量保障需要打破部门壁垒，让每个参与产品生命周期的人共同承担责任，避免在缓慢的退化中失去希望。
最悲哀的结局莫过于缓慢而痛苦的退化，没有任何治愈、慰藉、意义或希望，这便是所谓的千刀万剐。
HN 评论区
50- Bratmon
这篇文章非常散乱，不知怎么的，却偏偏漏掉了导致软件质量下降的最关键驱动因素：需求的变更。
你可以拥有最完美、最优雅的设计，利用世界上最棒的抽象，然后仅仅因为一次需求变更，就彻底摧毁这一切，让你的抽象完全失效。
- conqrr
如果有一个地方正在招聘，并且真正在乎软件质量，我愿意降薪 70% 去那里工作。
- bulatb
质量，不过是我们用来称呼“成功之物”与“我们希望成功之物”之间差异的词汇。它衡量的是，说“质量”这个词的人的观点，与客观存在的适应度函数（fitness function）实际奖励的内容在多大程度上吻合。当你听到“质量”这个词时，你唯一学到的只是说话者认为什么是好的，而不是关于该主题的任何事实。
质量只有在（人、偏好、主题）三者配对发生时才存在。它不是真实的，字面意义上就不存在。它只是一个用来混淆“实然”（is）与“应然”（ought）的标签。
当有人说“质量”并能指出具体让该主题具备质量的属性时，他们几乎总是在指出，从适应度函数的角度来看，那是一种低效，是能量和精力的浪费，是投入超过了系统所回报的部分。
任何投入大量精力培养技能以达成特定结果的人，都会相信这些结果很重要，至少是成功的必要组成部分，甚至就是成功的定义本身。当那些没有付出这些努力的人却能持续成功时，“质量”就成了他们的自我安慰（cope）。他们会说：那是粗制滥造的工作，他们做错了，他们肯定作弊了。
然而，他们确实成功了。
因为“质量”只是当“实然”与“应然”不匹配时，一个人所说的话。这是关于说话者的事实，而非关于主题的事实。
- Multicomp
Gene Kim 写了《DevOps 手册》，我想他至少还参与了相关的 DORA、《凤凰项目》和《独角兽项目》这些办公室叙事类书籍。结合这些书和 Google 的 SRE 书籍，我觉得自己非常有能力在软件开发生命周期（SDLC）中持续发挥价值，将即将到来的初级开发者大军——他们既是 AI 代理，有时也是人类——引导至正轨。
我还推荐 Xu 的《系统设计面试》第一卷和第二卷，用于逻辑系统设计的翻新；推荐《设计数据密集型应用》用于大多数公司的项目；推荐 Cockburn 的《六边形架构详解》，用于最终让从小类、模块到整个信息系统这样的大规模对象都拥有清晰的模块化边界，而无需在那些半忘半记的 SOLID 原则和 GoF 设计模式周围进行模糊的模式匹配，也不必盲目套用 12 要素应用设计原则。
过去，质量之所以被置于次要地位，是因为需要做的体力活太多了。AI 降低了做到卓越的成本，所以让我们在环境允许的范围内，尽可能做到卓越吧。
- tomhow
之前有过一篇……
如何思考软件质量（2022）- https://news.ycombinator.com/item?id=39490543 - 2024 年 2 月（66 条评论）