為什麼軟體工程的本質是管理複雜性

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