程序系统的复杂性

近来在做一些项目，对程序复杂性给开发带来的困难又有了进一步的认识。 对于一个从零开始的系统，我们要做的设计有以下这些工作：

1.  确定系统架构，具体讲就是要多少台机器， 每个机器上运行哪些应用程序，每个应用程序的功能是什么，这些程序通过什么接口技术进行交互。

2. 确定整个系统的数据模型。

3. 确定每个应用程序的数据结构，功能模块层次，模块之间的接口和接口调用规范，模块处理逻辑。程序之间的接口，接口调用规范。

4. 满足可靠性和性能要求，安全要求等等。

其中2，3项工作最为复杂。 定义整个系统的数据模型会因为现实世界中实体关系的复杂性变得异常麻烦，举棋不定确定不了一个最优的方案，数据会有冗余，还时常会在之后的开发工程中反复修正数据模型。比如对一个实体的分类有时就很复杂，很多的分类维度。有些维度之间是正交关系，有些维度之间不是正交关系；一个维度之下，一些个体确定属于一个类别，另一些个体同属于一个维度下的多个类别。 在做模型设计时，不论是程序的面向对象设计，还是数据库的面向关系设计，都很难设计的很好，冗余不可避免。

同样，模块功能逻辑也可能很复杂，好处是内部逻辑的复杂性不会影响其他模块。而一个模块接口的复杂性就会直接影响到其他模块，继而会由其他模块反作用于这个接口。很多接口设计是有很严格且复杂的接口调用规范，或者说调用上下文，调用场景假设。在实际开发过程中，总不断有新的功能要求或者性能要求打破这些限制，要求接口设计者不断地修改或者增添。这种修改增添又会因为要向前兼容变得让人很头疼。

 

信息技术发展这么多年，也不断推出新的开发方法论，希望能给程序开发找到银弹，让程序开发变得简单高效，开发出的程序变得稳定可靠。 但结论大家都知道，没有银弹。对于第2，3项工作，最依赖的还是资深的架构师和经验丰富的高级软件开发工程师。在这一点上，信息系统和其他行业确实有不同， 一个复杂信息系统的开发人员结构可能需要是纺锤型的而不是金字塔型的。一个砌砖的小工不会因为砌砖技术差让一座钢骨架大楼倒塌，一个不成熟的初级程序员却可以随便创造些越界，内存泄露让一个信息系统崩溃。

越来越多的平台，让我们开发一个系统在很多方面不需要从零开始。比如消息中间件完成分布式系统的异步通信，交易中间件帮助实现分布式事务，EAI平台完成异构数据的转换，SOA平台实现异构接口的互联互通，规则引擎完成规则的判断和推导等等。但这些平台都是业务无关的，不会帮你来做第2，3项的工作，它们只是工具，起到的是笔的功用，写文章还要作者自己来写。 对于复杂的信息系统，期待一个简单的图形化的统一开发平台，想拖拖拽拽组件图标就完成一个系统是不切实际的幻想。那是一些售前忽悠不懂行的甲方时经常勾画美好场景，在POC时做些简单的原型可能还行，当实际开发时这些标榜“不用编码”的开发平台就会逐步显示出其无法应付程序系统复杂性的本来面目。