为什么软件工程的本质是管理复杂性

软件工程是软件的形成过程，除了概念本身，涉及到了工具和人。主要是how，如何形成软件，如果使用技术，人又如何。软件工程的本质是复杂性

对软件工程而言，不可避免的东西是(需求）变化；而软件是的本质是概念和概念之间的关系，这个本质类似什么，类似于中子会影响原子裂变。

所以，这导致了软件的复杂性爆炸。

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

这里且不去论证他这个论断是否正确，但是的确反应了人月神话描述的软件工程面临的诸多难题

1，软件很容易陷入泥沼

2，陷入泥沼很难纠正调控

……

复杂性有三类

1，问题域本身的复杂性

2，采用的技术方案引入的额外复杂性

3，涉及到的人和组织再引入的额外复杂性

理解了这三个复杂性，就理解了为什么软件容易陷入泥沼，因为不能控制变化发生，就不能控制复杂性爆炸；

需求变化是变化，会引发复杂性爆炸

不能尽然计划可以视为一种计划外的变化

技术变化也是变化

组织变化也是变化

这些都会极大引发复杂度变化

 

软件工程 必须要解决这三个复杂性

成功的有效率的软件工程，需要引入技术熵和组织熵的概念

熵是能量中不能做功的能量

技术熵和组织熵是技术和组织在解决问题中，额外多花费的能量。

很明显，这两者越少越好。

所以，软件工程必须管理复杂性

1，技术熵越少越好

2，组织熵越少越好

3，良好的领域抽象，是真正的关键

4，如何去控制变化，隔离变化，适应变化

 

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

1，将软件按照时间阶段分为几个步骤（需求，设计，开发，测试，维护），这个划分是确保了完备性的

2，将每个步骤分配给一个或者几个角色，确保了这个划分是可执行，可管理，可组织的

3，微观上控制每一个步骤和节点的时间，风险，降低整体复杂性；提升可管理性

4，引入UML和工作协作方法（敏捷，瀑布……）来实现各个步骤之间的衔接和角色之间的衔接，确保整个理论是内洽的

 

这个理论，是一个管理性的理论，但没有解决任何软件工程的本质问题，只是确保了可管理性。

严格按照这个理论做的话，大概率可以提升软件的成功率的，但是效率和灵活性就难以保证了——这也是微软这种传统类型的软件公司和FG这种类型的软件公司的差异

 

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

 

https://my.oschina.net/u/3364724/blog/2098256?from=timeline&isappinstalled=0