春節前和同事在回家的路上看到了建筑工地，不由的感慨建筑業相比軟件業來講實在是成熟太多了！ 想想看，建筑師設計好圖紙，交給建筑公司（大包工頭）， 大包工頭再報給小包工頭， 小包工頭隨便抓一些農民工就可以干活了！ 農民工們可不懂得那么多高深的建筑原理， 對整個建筑也并不了解，可是他們只需要把自己的一磚一瓦做好，整個建筑就能做成了 -- 當然也有豆腐渣工程-- 但畢竟是少數，排除在外。

?

更重要的是他們根本不用擔心項目的后期客戶突然想改設計方案，客戶不會也不可能要求你把朝北的窗戶挪到南邊去，也不會要求把10層樓中的第3層和第7層扒掉重蓋。

?

我們這些苦苦掙扎的碼農們肯定會想， 什么時候軟件業也能這樣啊，什么時候我們也能快樂編程，按時上下班，或者以后這些底層的Labor work都讓機器人做了， 我們都去做需求，架構，設計， 然后項目按進度，高質量的完成， 大家都很happy...

?

但是無數的無情現實告訴教育我們：別做夢了，這是絕對不可能的， 至少在可以預見的時間段(比如50年)是不可能的， 原因就在于軟件的復雜性，在現有的技術情況下， 軟件的固有復雜性無法解決， 只有依靠我們這么碼農們去彌補。

?

為什么軟件這么復雜， 為什么我們無法像建筑業蓋房子，汽車業裝配汽車一樣去寫軟件？

?

1. 需求的復雜性

?

布魯克斯在著名的《人月神話》中提到軟件的內在復雜性， 的確，軟件系統的復雜性遠遠超過建筑業和制造業， 軟件的需求是在人的腦子中的， 用自然語言都很難完整、準備的表達出來。? 一般情況下，人們只有看到一個運行的系統以后才會說： “奧， 我要的其實不是這個... ” 這是傳統的瀑布方法失敗的重要原因。 需求的不確定性是導致軟件復雜的重要原因。

?

2. 原始的工具

?

即使需求很復雜，如果我們有強大的， 靈活的工具， 比如以自然語言來寫程序， 我們也能處理。

?

但現實是殘酷的， 我們只有計算機語言， 它相當的原始， 從二進制語言，到匯編語言，再到高級語言，其最基本的、最核心的東西依然是順序，循環，分支， 即使加上面向對象，動態語言，庫， 框架，計算機語言的本質仍然沒有改變，就像牛頓三定律一出現，整個力學大廈已經建立起來了，后人只是在大廈和某些房間里做裝飾而已，? 使用計算機語言這種原始的工具，怎么能夠表示復雜的需求？?

?

3. 軟件組件之間的高耦合性

?

程序員的出現正是為了填充復雜的需求和原始工具之間巨大鴻溝，程序員需要用自己的大腦，使用極其”原始“的工具， 把無法準確表述的，尚在腦子中的需求映射到可執行的代碼上，其難度可想而知！

?

當然我們程序員也不笨， 在長期的斗爭中，我們學會了分而治之，把一個問題劃分為一個一個的模塊， 讓這些模塊低耦合，高內聚，? 我們還學會了分層，讓各個部分的聯系達到最小， 可是所有的這些努力只是把復雜性降低了一點， 本質的復雜性依然存在。

?

普利司通制造的輪胎幾乎可以用到所有的汽車， 但是我們程序員無法開發一個登錄模塊，讓它用到所有的軟件系統中， 我們程序遠遠必須要對這些框架，庫進行定制，進行二次開發才能適應需求，這樣的工作必須通過手工完成。

在某些業務領域例如電力，金融，財務等也許能出現一些重用性很強的“輪胎”， 但很明顯不具備更大范圍的通用性。

?

?

所以在現有的條件下， 不管用什么技術，組成軟件的各個組件之間依然是高耦合的(對應傳統產業而言)， 高耦合會帶來巨大的難以想象的復雜度。

?

總結

以上是生活随笔為你收集整理的软件为什么这么复杂的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。