软件设计的两句箴言
2010年5月13日 · Max Kanat-Alexander
在《软件设计方程》的背景下，现在可以将软件设计的主要原则简化为两句话：
- 降低维护成本比降低实现成本更重要
- 维护成本与系统复杂度成正比
这就是核心。如果你只了解这两条原则和软件的目的，就可以推导出软件开发的所有其他通用原则。
——Max
读者讨论精选
Mark Castillo（2010年5月13日）：
嘿嘿…我还在寻找“实现和维护零成本”的原则。也许这里可以总结为：“零成本是不可实现的”。
Wanderson Santos（2010年5月18日）：
完全同意，但能否将其与敏捷原则（如XP中的“简单设计”）对齐？
Max回复：
我不完全认同任何现有的软件方法论。如果有人觉得这些原则与XP类似并能结合使用，那很好。但如果只是为了强行对齐而对齐，则意义不大。方法论推广者往往带有利益动机（如卖书或咨询），但不应仅因利益而传播观点。
Ape（2010年6月12日）：
能否举例说明如何从这两条原则推导其他原则？
Max回复：
- 降低复杂度：松散耦合能减少组件间依赖，从而降低复杂度。
- 减少维护时间：自动化测试能提前捕获缺陷，减少后期修复时间。
几乎所有软件开发原则（除人机交互外）均可由此衍生。
Harald Wellmann（2010年10月27日）：
维护成本与系统规模的关系可能非线性（如O(c log c)或O(c²)）。
Max回复：
更准确的表述应为“维护成本是系统复杂度的函数”，但为避免理解障碍，保留了原表述。
Mike W.（2017年9月21日）：
“维护成本与复杂度成正比”使用的是日常语义。若用数学表达可改为：“系统复杂度增加时，维护成本增加。”
延伸思考
技术债务的真相（Max Kanat-Alexander, 2017年6月4日）
技术债务的价值多是神话。糟糕的工程决策会在几小时到几周内拖慢进度。正确的设计通常只需多花几小时，且能立即收回成本。长期累积的债务会导致系统陷入无法修复的泥潭。
如何应对变更抵触（Max Kanat-Alexander, 2010年5月29日）
用户对系统变更的负面反馈常源于“变更厌恶”而非真实问题。可通过以下方式区分：
- 抵触情绪通常在3-10天内消退；
- 情绪化反馈（如“新菜单颜色难看”）多为抵触，而事实性反馈（如“性能下降10倍”）需认真对待。
本文通过简洁原则揭示了软件设计的本质，并辅以实例和讨论，为开发者提供了实用指导。