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

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

軟體工程是軟體的形成過程，除了概念本身，涉及到了工具和人。主要是how，如何形成軟體，如果使用技術，人又如何。軟體工程的本質是複雜性

對軟體工程而言，不可避免的東西是(需求）變化；而軟體是的本質是概念和概念之間的關係，這個本質類似什麼，類似於中子會影響原子裂變。

所以，這導致了軟體的複雜性**。

這也是為什麼《人月神話》作者在論述到這個本質和變化的時候說：「如果這是事實，那麼終究沒有銀彈」。

這裡且不去論證他這個論斷是否正確，但是的確反應了人月神話描述的軟體工程面臨的諸多難題

1，軟體很容易陷入泥沼

2，陷入泥沼很難糾正調控

……複雜性有三類

1，問題域本身的複雜性

2，採用的技術方案引入的額外複雜性

3，涉及到的人和組織再引入的額外複雜性

理解了這三個複雜性，就理解了為什麼軟體容易陷入泥沼，因為不能控制變化發生，就不能控制複雜性**；

需求變化是變化，會引發複雜性**

不能盡然計畫可以視為一種計畫外的變化

技術變化也是變化

組織變化也是變化

這些都會極大引發複雜度變化

軟體工程必須要解決這三個複雜性

成功的有效率的軟體工程，需要引入技術熵和組織熵的概念

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

技術熵和組織熵是技術和組織在解決問題中，額外多花費的能量。

很明顯，這兩者越少越好。

所以，軟體工程必須管理複雜性

1，技術熵越少越好

2，組織熵越少越好

3，良好的領域抽象，是真正的關鍵

4，如何去控制變化，隔離變化，適應變化

傳統的軟體工程理論是無法解決這個問題的，我們先來看一下傳統的軟體工程理論是個什麼東西

1，將軟體按照時間階段分為幾個步驟（需求，設計，開發，測試，維護），這個劃分是確保了完備性的

2，將每個步驟分配給乙個或者幾個角色，確保了這個劃分是可執行，可管理，可組織的

3，微觀上控制每乙個步驟和節點的時間，風險，降低整體複雜性；提公升可管理性

4，引入uml和工作協作方法（敏捷，瀑布……）來實現各個步驟之間的銜接和角色之間的銜接，確保整個理論是內洽的

這個理論，是乙個管理性的理論，但沒有解決任何軟體工程的本質問題，只是確保了可管理性。

嚴格按照這個理論做的話，大概率可以提公升軟體的成功率的，但是效率和靈活性就難以保證了——這也是微軟這種傳統型別的軟體公司和fg這種型別的軟體公司的差異

至於正確的方式，回頭慢慢聊

為什麼軟體工程的本質是管理複雜性軟體工程是軟體的形成過程，除了概念本身，涉及到了工具和人。主要是how，如何形成軟體，如果使用技術，人又如何。軟體工程的本質是複雜性對軟體工程而言，不可避免的東西是需求變化而軟體是的本質是概念和概念之間的關係，這個本質類似什麼，類似於中子會影響原子裂變。所以...

軟體工程的本質問題域到不同抽象層之間概念和計算邏輯的對映.從問題域到開發平台直接進行對映，勢必存在一定的複雜性。為了控制這一複雜性，需要確定多個抽象層，例如需求設計實現和部署等，每乙個抽象層均由自己特定的術語定義，形成該抽象層的乙個術語空間。如果按照自頂向下的途徑進行軟體開發的話，首先就是通...

1 問題域的複雜性，造成這種複雜性的主要原因，還是使用者與開發者之間的溝通問題使用者常常對某個需求只存在乙個模糊的概念，對具體要實現成乙個什麼樣子沒有特別明顯的想法。並且由於使用者與開發者思維的不一致，使用者很難將他的意思很清晰的傳達給開發者。通常這種情況下，我們開發者也只能借助些工具，例如...