为什么我们不同意罗伯特·马丁的主张： “缺陷是程序员的错。造成缺陷的是程序员，而不是语言。” 我说这是他的哲学的重大缺陷。
从表面上看，这听起来很明显。缺陷来自代码，程序员编写代码，因此缺陷来自程序员。
许多最讨厌的bug来自这些组件：单独隔离时正确，但以危险方式交互调用时候出现Bug。这称为功能交互错误。您可以证明这既是人的错，又不是人的错，也不是经理的错，谁知道是谁的错呢；另一组危险的bug来自模棱两可的需求。有多种方法可以完全合理地解释需求，即使客户不知道他们打算使用哪一种词语来表达。
功能交互和模棱两可的需求的两者错误可能来自于缺乏正式规范这样的前期设计方法。因此，您可以说这也是程序员不编写规范的错。
“程序员创建缺陷”这个更大的问题是世界观的基本问题。实际上，其远不如作为我们可以用来理解缺陷的“解决方式”的价值重要。如果我们知道缺陷来自何处，就知道我们需要做什么来进行管理。
“缺陷是程序员的错”的世界观如何告诉我们什么解决手段呢？它说减少缺陷的唯一方法是提高程序员的纪律性（banq注：把焦点聚焦在“人”身上，而不是就事论事，聚焦在“事情”上）。程序员受过足够的纪律约束，就没有任何东西可以导致缺陷。马丁本人将他的世界观描述为：
原因：
- 在时间表压力下，太多的程序员采用草率的捷径。
- 太多其他程序员认为这很好，并提供掩护。
显而易见的解决方案：
- 提高软件纪律和专业水平。
- 切勿为草率的工作找借口。
这就是为什么马丁建议程序员做：
- 单元测试（专门用于测试驱动的开发）
- 代码审查
- “清洁代码”
- 配对编程
这就是为什么马丁将可空类型之类的语言特性称为“黑暗之路”，而形式规范则称为“ 闪亮 ”。他的解决方案都与项目的结构、程序员使用的工具、所处的环境等无关。
注意这给我们带来的好处！因为所有缺陷都来自程序员，所以我们只能在很窄范围谈论消除缺陷的事情。也许Bug是每个人都过度劳累，我们需要雇用另一个程序员吗？如果我们的微服务架构使某些类型的错误更有可能发生怎么办？仍然是你没有纪律。
在安全科学界，这被戏称为“人为错误”。人为失误是人们停止调查的地方。只是替罪羊，让更广泛的体系摆脱苏格兰的束缚。不要问设备是否过时，培训计划资金是否不足或官方程序是否与地面现实脱节。当所有缺陷都是人的错时，除了责怪人类之外，我们没有任何其他工具可以解决缺陷。这对于我们的目的来说是完全不够的。
我想举一个例子说明“缺陷是程序员的错误”和“缺陷是系统的复杂属性”之间的鸿沟：早在2018年，JavaScript世界就发生了巨大的纠缠，因为一个被广泛使用的软件包被恶意参与者接管了。每个人都在谴责这些坏人。许多人指责原始软件包的维护者将其提供给恶意行为者，许多人指责那些升级了依赖关系而未先审核代码的公司。我不是JavaScript世界的一部分，但想练习我的事故分析技能，所以我参与其中。最终分析花了两个月的时间来撰写并确定了更广泛系统的15个属性，这些属性使攻击变得可行，并且有可能在未来再次发生。其中一些易于修复，而其他一些则涉及可用性和安全性之间甚至安全性与不同安全性之间的基本权衡。所有这些都只是想责怪程序员而错过。
（banq注：将注意力焦点从人身上转移到事情上，还能避免道德绑架）
“缺陷是程序员的错”听起来不错，但它无助于我们修复缺陷。