软件的本质

1，为何说软件的本质是概念和概念之间的关系
由于不管怎么简化，去掉实现差别，框架差别，语言差别，软件的本质最终不能再简化为一个问题域——即一些概念和他们的关系。

或者用另一个表达式 程序 = 数据 + 逻辑
这个表达式在OO时代进化为：程序 = 对象+对象+对象…… && 对象 = 数据+逻辑
对象模型，很明显更能贴切的去表达概念和关系

2，为何软件工程的本质是管理复杂性

软件工程是软件的造成过程，除了概念自己，涉及到了工具和人。主要是how，如何造成软件，若是使用技术，人又如何。软件工程的本质是复杂性
对软件工程而言，不可避免的东西是(需求）变化；而软件是的本质是概念和概念之间的关系，这个本质相似什么，相似于中子会影响原子裂变。
因此，这致使了软件的复杂性爆炸。

这也是为何《人月神话》做者在论述到这个本质和变化的时候说：“若是这是事实，那么终究没有银弹”。


这里且不去论证他这个论断是否正确，可是的确反应了人月神话描述的软件工程面临的诸多难题
1，软件很容易陷入泥沼
2，陷入泥沼很难纠正调控
……

复杂性有三类
1，问题域自己的复杂性
2，采用的技术方案引入的额外复杂性
3，涉及到的人和组织再引入的额外复杂性

理解了这三个复杂性，就理解了为何软件容易陷入泥沼，由于不能控制变化发生，就不能控制复杂性爆炸；
需求变化是变化，会引起复杂性爆炸
不能尽然计划能够视为一种计划外的变化
技术变化也是变化
组织变化也是变化
这些都会极大引起复杂度变化

 

软件工程 必需要解决这三个复杂性
成功的有效率的软件工程，须要引入技术熵和组织熵的概念
熵是能量中不能作功的能量
技术熵和组织熵是技术和组织在解决问题中，额外多花费的能量。
很明显，这二者越少越好。

因此，软件工程必须管理复杂性
1，技术熵越少越好
2，组织熵越少越好
3，良好的领域抽象，是真正的关键
4，如何去控制变化，隔离变化，适应变化

 

传统的软件工程理论是没法解决这个问题的，咱们先来看一下传统的软件工程理论是个什么东西

1，将软件按照时间阶段分为几个步骤（需求，设计，开发，测试，维护），这个划分是确保了完备性的
2，将每一个步骤分配给一个或者几个角色，确保了这个划分是可执行，可管理，可组织的
3，微观上控制每个步骤和节点的时间，风险，下降总体复杂性；提高可管理性
4，引入UML和工做协做方法（敏捷，瀑布……）来实现各个步骤之间的衔接和角色之间的衔接，确保整个理论是内洽的

 

这个理论，是一个管理性的理论，但没有解决任何软件工程的本质问题，只是确保了可管理性。
严格按照这个理论作的话，大几率能够提高软件的成功率的，可是效率和灵活性就难以保证了——这也是微软这种传统类型的软件公司和FG这种类型的软件公司的差别

 

至于正确的方式，回头慢慢聊