软件简洁性的定义
多年前，我曾写过一篇博文指出计算机系统的问题本质在于复杂性。几年后出版的《代码简洁性》一书，系统阐述了简洁性为何是软件最重要的品质。
但在与世界顶尖软件工程师的研讨中，我震惊地发现：从来没有人正确定义过软件的"简洁性"是什么。人们对此有各种误解：
- “看，现在代码行数变少了，所以更简洁！”
- “这个系统使用了XX设计模式，所以更简洁！”
- “这个系统完全通用化，遵循了所有最佳实践，这算简洁吧？”
正确定义
对软件而言，“简洁"意味着易于阅读、理解并正确修改。这个定义包含三个关键点：
- 人类因素：简洁性本质是人类的感知，与机器无关。自动化重构工具能辅助简化，但最终需要人工参与
- 不可自动化测量：无法用工具量化代码简洁度，必须通过开发者反馈评估。情绪反应（挫败感/恐惧感）是重要指标
- 需要持续投入：必须有专人负责代码（非问责制的"拥有”），否则代码会随时间自然复杂化
复杂性的根源
1. 缺乏所有权
无人维护的代码必然走向复杂。在物理世界中，所有未被持续维护的系统都会熵增——软件也不例外。
2. 时间压缩
开发者因各种压力（真实或想象的）选择走捷径：
- " deadline太紧必须取巧"
- “那个库太难用只能这样hack” 本质上都是"不愿花时间修复根本问题"的变体
实践建议
- 警惕纯工具化方案：工具可以辅助，但不能替代人工简化
- 建立验证机制：通过代码审查、结对编程达成简洁性共识
- 控制变更节奏：避免"大爆炸式"变更引发用户抵触
- 技术债务真相：大多数情况下，正确实现与草率实现耗时相当，但技术债务会指数级增加后续成本
“当我每天写代码时，我对简洁性绝对不妥协。奇怪的是，这样反而从未错过任何截止期限。"——作者实践心得
读者讨论精选
Steven Gordon博士指出：
- 简洁性存在主观差异，应通过共享所有权、结对编程等达成共识
- 代码所需注释量可作为简洁性反向指标
Kurt Guntheroth补充：
- 应考虑上下文约束（如OS内核模块不可能像CRUD界面那样简单）
- “相对简洁度"比绝对标准更具可操作性
作者回应强调：
- 如同写作需要考虑读者视角，代码也应针对目标开发者群体优化
- 不存在完美方案，但存在上下文最优解