为什么我们无法开发出简单的软件？——Peter van Hardenberg的深度思考

在软件开发中，复杂性是一个永恒的话题。Peter van Hardenberg（曾任职于Heroku、参与游戏开发和数据库工作，现从事增强人类智能的研究）在一次演讲中深入探讨了软件复杂性的本质、来源以及应对策略。本文基于他的演讲内容，重新梳理并优化为适合网页阅读的结构化文章。

复杂性的定义：不仅仅是“困难”

复杂性（Complexity）与难度（Difficulty）不同。难度指学习或实现某事物的挑战性，而复杂性源于系统内部组件的相互作用，导致不可预测的行为。例如，微积分概念可能难以掌握，但本身是简单优雅的；相反，一个软件系统可能因组件间意外交互而变得复杂，难以推理和维护。

复杂性可分为两类：意外复杂性（Accidental Complexity）和本质复杂性（Essential Complexity）。意外复杂性来自技术债务、糟糕的设计或外部约束（如兼容性需求），而本质复杂性是问题域固有的、不可简化的部分（如模拟物理过程）。识别这两者有助于优先处理改进点。

复杂性的常见来源

软件复杂性并非一蹴而就，而是随着时间推移，通过多种途径累积而成。以下是几个关键来源：

1. 输入验证和边缘情况处理

初始代码往往只处理“快乐路径”（Happy Path），但真实环境要求处理异常输入、错误状态和边界条件。例如，一个简单的Web应用可能开始时直接查询数据库，但随后必须添加输入验证、空值检查和错误处理。这可能导致“散弹式解析”（Shotgun Parsing），即验证逻辑分散在整个代码库中，增加安全漏洞风险。

解决方案：利用类型系统、库或框架将复杂性下推，例如使用强类型语言自动处理null检查，减少手动维护状态的需要。

2. 规模变化带来的挑战

系统规模扩大时，不仅性能特征变化，问题本质也可能改变。例如，一个用户管理面板在10个用户时简单列表即可，但到100万用户时需分页、搜索甚至处理伦理和法律问题（如滥用检测）。规模变化引入新维度复杂性，如分布式系统中的延迟、故障和排序问题。

建议：避免过度设计——为未来规模构建系统可能使当前系统难以使用，应保持规模 appropriateness，逐步演进。

3. 抽象泄漏（Leaky Abstractions）

抽象旨在简化复杂性，但不完美的抽象会“泄漏”底层细节。例如，C语言的strcpy函数接口简单，但现代实现涉及数百行汇编代码以处理内存对齐和性能优化。这表面简单，实则隐藏了巨大复杂性，可能导致性能陷阱或理解缺口。

影响：开发者可能误以为系统简单，直到泄漏的细节导致问题。权衡抽象的好处与透明度至关重要。

4. 模型与现实差距

当软件模型与真实世界不匹配时，复杂性增加。例如，将姓名拆分为“名”和“姓”假设空格分隔，但许多文化中姓名结构不同（如“van Hardenberg”）。这导致数据错误和hacky修复。

示例：W3C有关个人姓名的文章建议使用“全名”字段而非拆分字段，以更好反映多样性。分布式系统中，心智模型与真实行为差异也会引发意外问题。

5. 多维环境复杂性

支持多种平台、浏览器、设备或网络条件时，复杂性乘数效应出现。每个新维度（如iOS、Android、Web）增加测试、维护和协调开销。例如，使用Electron等跨平台工具可能简化开发，但牺牲性能或原生体验。

策略：最小化环境差异，或采用隔离复杂性 approach，如通过抽象层封装平台特定代码。

复杂性稳态：为什么工具改进不总是有效

类似风险稳态（Risk Homeostasis）——如安全带使驾驶更安全但鼓励风险行为——软件也存在复杂性稳态（Complexity Homeostasis）。组织或个人有内在复杂性容忍度，当工具或方法简化系统时，人们倾向于添加新功能或挑战，从而恢复复杂性水平。

这意味着：

• 更好工具不减少总体复杂性，而是允许做更多事。
• 复杂性预算受团队技能、业务目标和文化影响（如高收入项目可能容忍更多复杂性）。
• 重启项目（如新编程语言）可重置复杂性时钟，但只是临时缓解。

历史支持这一点：Jeff's Paradox指出，引擎效率提升未减少煤耗，因为人们做了更多工作；软件工程定律（如Lehman's Laws）表明成功系统随需求增长而演变。

理论与研究：理解复杂性本质

软件复杂性研究已有数十年历史。关键见解包括：

• Out of the Tarpit论文（2006）：区分意外与本质复杂性，强调通过简化架构减少意外复杂性。
• Berkeley DB团队论述：软件架构随更改而衰减，需要持续维护来保持清晰性。
• Excel团队 motto：“查找并消除依赖”——减少外部依赖以控制复杂性。

复杂性并非总是坏事：它 enable 涌现属性（Emergent Properties），如游戏中的意外玩法（《塞尔达传说：荒野之息》的化学引擎），但需谨慎 harness。

应对复杂性的策略

既然复杂性不可避免，如何管理它？Peter 建议多种方法：

1. 重启项目（Starting Over）

新项目开始时复杂性低，允许从头设计。例如，创建新编程语言或框架可清除历史债务。但这是短期解决方案，长期复杂性仍会累积。

2. 削减范围和依赖（Doing Less with Less）

限制平台、功能或环境可简化系统。例如，PlayDate手持设备只有黑白屏幕和有限硬件，但 enable 高度优化和抛光。减少依赖（如Excel自带编译器）增加控制力。

3. 隔离复杂性（Isolating Complexity）

通过模块化、分层或抽象将复杂性封装在特定区域。例如，微服务架构隔离服务间复杂性，但引入协调开销。

4. 拥抱复杂性（Embracing Complexity）

有时复杂性是创新的源泉。 deliberate 接受复杂性，如构建生成式系统（游戏引擎），但需谨慎管理代价。

5. 本地优先软件（Local-First Software）

Peter 的研究实验室 Ink and Switch 探索本地优先软件，如使用 Automerge（类似Git的数据结构）构建协作应用，运行在用户设备上而非云，减少外部依赖和复杂性。这提供 agency 和所有权，但挑战协作设计。

结论：与复杂性共处

软件复杂性是系统交互、组织行为和演进需求的自然结果。无法消除，但可管理：

• 识别复杂性来源（如输入验证、规模、抽象泄漏）。
• 接受复杂性稳态——工具改进不减少总体复杂性，但 enable 更多功能。
• 采用策略如重启、削减范围、隔离复杂性或拥抱它。

正如自行车手Greg LeMond所说：“It never gets easier, you just go faster.” 软件开发中，我们无法使复杂性消失，但可以通过更好理解和工具变得更高效。

注：本文基于Peter van Hardenberg的演讲内容，专有名词如Heroku、Automerge等保留英文原称。演讲中提及的研究和概念已简化以适应文章格式。