軟件的本質

1，爲何說軟件的本質是概念和概念之間的關係
由於不管怎麼簡化，去掉實現差別，框架差別，語言差別，軟件的本質最終不能再簡化爲一個問題域——即一些概念和他們的關係。

或者用另一個表達式 程序 = 數據 + 邏輯
這個表達式在OO時代進化爲：程序 = 對象+對象+對象…… && 對象 = 數據+邏輯
對象模型，很明顯更能貼切的去表達概念和關係

2，爲何軟件工程的本質是管理複雜性

軟件工程是軟件的造成過程，除了概念自己，涉及到了工具和人。主要是how，如何造成軟件，若是使用技術，人又如何。軟件工程的本質是複雜性
對軟件工程而言，不可避免的東西是(需求）變化；而軟件是的本質是概念和概念之間的關係，這個本質相似什麼，相似於中子會影響原子裂變。
因此，這致使了軟件的複雜性爆炸。

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


這裏且不去論證他這個論斷是否正確，可是的確反應了人月神話描述的軟件工程面臨的諸多難題
1，軟件很容易陷入泥沼
2，陷入泥沼很難糾正調控
……

複雜性有三類
1，問題域自己的複雜性
2，採用的技術方案引入的額外複雜性
3，涉及到的人和組織再引入的額外複雜性

理解了這三個複雜性，就理解了爲何軟件容易陷入泥沼，由於不能控制變化發生，就不能控制複雜性爆炸；
需求變化是變化，會引起復雜性爆炸
不能盡然計劃能夠視爲一種計劃外的變化
技術變化也是變化
組織變化也是變化
這些都會極大引起復雜度變化

 

軟件工程 必需要解決這三個複雜性
成功的有效率的軟件工程，須要引入技術熵和組織熵的概念
熵是能量中不能作功的能量
技術熵和組織熵是技術和組織在解決問題中，額外多花費的能量。
很明顯，這二者越少越好。

因此，軟件工程必須管理複雜性
1，技術熵越少越好
2，組織熵越少越好
3，良好的領域抽象，是真正的關鍵
4，如何去控制變化，隔離變化，適應變化

 

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

1，將軟件按照時間階段分爲幾個步驟（需求，設計，開發，測試，維護），這個劃分是確保了完備性的
2，將每一個步驟分配給一個或者幾個角色，確保了這個劃分是可執行，可管理，可組織的
3，微觀上控制每個步驟和節點的時間，風險，下降總體複雜性；提高可管理性
4，引入UML和工做協做方法（敏捷，瀑布……）來實現各個步驟之間的銜接和角色之間的銜接，確保整個理論是內洽的

 

這個理論，是一個管理性的理論，但沒有解決任何軟件工程的本質問題，只是確保了可管理性。
嚴格按照這個理論作的話，大機率能夠提高軟件的成功率的，可是效率和靈活性就難以保證了——這也是微軟這種傳統類型的軟件公司和FG這種類型的軟件公司的差別

 

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