為什麽軟件工程的本質是管理復雜性

軟件工程是軟件的形成過程，除了概念本身，涉及到了工具和人。主要是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

軟件工程的本質是管理復雜性