两次软件危机的根本原因：逻辑复杂与扩展复杂

软件工程史上两次被称为”危机”的困境，虽然表现形式相似（质量低下、项目延期、严重超支），但根本原因并不相同，理解这个差异能帮助判断一种方法论到底能解决什么问题、解决不了什么问题。第一次软件危机爆发于20世纪60年代中期，根源在于软件的”逻辑”变得非常复杂——高级语言让程序员摆脱了面向机器的思维负担，但软件规模一大，代码内部的执行流程和分支逻辑本身就变得难以理解和掌控，典型例子是IBM System/360操作系统项目投入5000人年、近百万行代码却依然进度失控、质量堪忧。应对这次危机的方案是结构化程序设计——抛弃goto语句，用”自顶向下、逐步细化、模块化”的方法把逻辑复杂度控制在可管理的范围内。第二次软件危机爆发于20世纪80年代，根源不再是逻辑本身的复杂，而是软件的”扩展”变得非常复杂——随着硬件飞速发展、业务需求越来越复杂、应用领域越来越广，结构化程序设计虽然能缓解逻辑复杂度，但对”业务变化带来的软件该怎么扩展”却无能为力。应对这次危机的方案是面向对象思想的流行（主要靠C++推动，后来Java、C#把它推向高峰）。两次危机、两种应对方案说明同一个道理：一种方法论能解决的往往只是它诞生时所针对的那类具体复杂度，逻辑复杂度和扩展复杂度是两类不同的问题，用解决逻辑复杂度的思路去应对扩展复杂度的挑战注定收效有限。