經常有用建築比喻軟體工程，那建築是否也會出現軟體那樣的致命錯誤？

01-15

程序員經常拿自己的工作比作摩天大樓，但現實中很少看到摩天大樓因為一個致命錯誤就倒掉的吧，或者設計大樓的工程師，在大樓蓋好後才發現自己原來的設計有個致命缺陷會導致大樓垮塌等。如果用程序員做軟體的方式蓋房子，結果會是，呵呵。
我的問題是：
1.建築工程里用了什麼方法導致蓋出來的房子不像軟體工程那樣錯誤百出？
2.這種方法對軟體工程是否有借鑒意義？

更新：看到 @ringo和 @狼大人的評價之後，我突然意識到我的答案可能會被誤解為是在為軟體工程的「糟糕」質量辯護。其實我並不認同題主的諷刺之意，只是看到這個問題忍不住從軟體工程的角度講了一下軟體行業中Quality Assurance的標準和原因。我認為如果嚴格按照致命缺陷的概念，題目的比喻就是有問題的，可以跟大樓類比的同等規模的軟體不會像題主想像得那樣「有個致命缺陷會導致大樓垮塌」。的確有時細小的bug也會導致整個程序崩潰，但如果不是軟體整體出現了大問題，這個bug是可以在合理的時間和代價內fix的，在軟體工程領域之內，我不認為這算是致命缺陷。「像軟體工程一樣錯誤百出」很大程度上是題主誇大了所謂致命缺陷，質量不好的軟體跟質量不好的建築一樣，通常在各個構件層面上都會有一定的缺陷，累加起來形成一個糟糕的產品。好的開發流程避免不了小bug，但是一定能（並且應該）避免這種全局的缺陷。這一點上我認為軟體業和建築業沒有區別。所以如果不把到擴展到較為普通的bug層面來答，題主的問題就有點像是樹個稻草人來批了。如果問的是「為什麼軟體比建築更容易出錯」，下面是我認為的一部分原因：

================原答案==================

原因和結果反了。不是因為軟體工程的方法論有問題所以寫出來的程序（相比建築）穩定性差，而是因為大多數場合下對於軟體的需求允許用開發效率、運行效率犧牲穩定性，因而開發過程中不會像建築設計一樣對安全極度保守。

說到底軟體本來就是expected to fail的，只要fail之後恢復起來很容易（軟體本身的特點），為什麼一定要保證一個軟體在生命周期中一定不會fail？

以及軟體不像建築，可以不斷迭代更新升級的，這次有bug下次fix了就好嘛。

以及，很多軟體被發現bug是因為他們面對的數量極大的測試（不管是QE還是用戶執行的），並且充滿了各種極端情況。很少有建築可以像這樣被thoroughly地重複測試（e.g, 如果用戶把他的住宅用房間改造成了超音速風洞，會對建築的穩定性有影響嗎？覺得不太可能所以沒有考慮？在軟體里用戶很有可能會比這個還誇張地使用你的軟體~）

以及，大型軟體的複雜性遠超過一般的建築（上千個工程師幾年時間的開發）。如果像迪拜塔一樣的建築可能複雜性差不多，這一點留待各位建築師指正。

Last but not least，如果是把穩定性放在第一來考慮的高質量軟體，其實質量是很好的.....比如很多軍工的系統。

建築當然有致命錯誤垮掉的時候。

軟體運行應該也有個運行環境，建築同樣如此，抗震設計有致命錯誤，建築結構就會塌掉；機電設計有致命錯誤，空調設備在極端天氣中也會「宕機」。

如果說程序出現致命錯誤頻率更大，我更傾向於認為程序的電子運算的迭代速度遠遠超過比建築運行迭代速度快導致的。有的建築可能在其全生命周期內也沒有出現其設計的運行環境，所以不會出現「致命錯誤」。

另外，還有一個我能想到的原因，是人類從事建造活動的歷史很長，其對建築的建造經驗已經通過制度、標準、規範、圖集和書籍等文本形式固化下來了，進一步降低了設計、施工、運行人員的犯錯幾率。

————————更新22：10————————————————————————

看了幾位知友的回答，更新一下我的想法。

1：同意 @彭斯的回答，我認為不管是軟體還是建築，其崩潰造成的後果的嚴重性和其運行的穩定性成正比。這應該是所有工程學科的共性。

2：一開始同意 @崔飄揚的回答，後來想想，覺得有點不妥，取消掉了。

3：軟體試錯出現在開發調試階段，對應的是建築的設計階段。建築也有類似的試錯，例如模型，以前建築師會建立結構模型進行測試其結構穩定性和構件受力情況，現在會利用計算機模型進行各種模擬計算。道理都是一樣的，兩者沒差。建築在設計階段也會有expected to fail的情況。典型的如BIM模型，我們建立BIM模型的目的之一其實就是希望看一下有沒有構件碰撞的情況，結果會有百十個碰撞，然後再一一調整。

4：建築剛投入使用，甚至往後很長的一段時間內，其實也是小bug不斷的，需要工程和物業人員一一去處理，這就是建築調試階段。也有出現因為調試不成功，導致某個系統廢掉的情況。這種時候，由於會造成一定的無法彌補的損失，所以不會有哪個建築師或業主會expected to fail了。

謝邀

我非常贊同 @崔飄揚的觀點。另外房子真的比軟體的bug少嗎？不見得吧。

1、結構設計要求有較高的可靠度，對於承載能力構件，可靠度為3.7，甚至4.7。這意味著構件的失效概率是百萬分之一這個數量級的。如此可靠度的得到，是通過在設計中考慮大量的分項係數，總體來說就是把荷載放大，強度打折，這樣子得到。因此結構設計會比較保守；

而軟體，我想也有冗餘機制，但是其程度與結構設計是否相當？

2、房子，起皮，滲水，開裂，這些不致命的bug其實是無處不在，估計數量遠遠高於軟體的bug數量，只是大家的容忍程度不一樣而已；

3、這點我覺得最關鍵，誰把房子拿來做過滿荷載測試？橋樑有做荷載試驗，也只是做到正常使用極限狀態，不敢做到承載能力極限狀態。房子在日常使用過程中，荷載遠小於設計的荷載。如果哪天荷載真的達到設計值，房子掛不掛還兩說呢。而軟體呢，天天被無數人以無數奇葩的方法使勁折騰，軟體測試甚至是過載測試吧？房子如果這麼折騰啊，早掛了啊。

樓上說的都是……。

作為現場施工技術人員，深刻感受到，建築致命bug基本可以沒有。

只要按圖施工，現成的力學計算步驟和方式，不需要創新，按部就班，能錯成什麼樣？

抽掉四分之一鋼筋也不會有什麼事情，砼標號小一點也不會有事，遇見十級地震再結實也沒用。

哦，據說天津某地從開始就少了一根關鍵的KZ也干到頂了。。。。

哦，據說xx某地牆柱鋼筋沒按規定綁紮，也干到頂了，，，，，，

嗯，，，，，建築這個多少年沒有什麼變化的學科，各種進展緩慢，研究也沒什麼大的實際應用，（略片面，不過事實就基本就是這樣）。

所以啊，不建議學習研究建築方面太多的東西，會有個頂，會讓你不敢突破（突破試試？萬一有個閃失，GO了就），建築，還是做設計吧。變著花樣就成了，研究什麼各大力學，還不如去玩機械。

軟體工程不一樣，bug是堵不完的，建築上的小缺陷根本可以忽略，不會影響到整體。

so。

一個產品的品質，都是和它能產生的收益成正比，和它可能產生的最壞後果的嚴重程度成正比。

貧尼上研究生的時候有一個好朋友是土木工程的博士。她當時在研究抗震方面，她們的實驗室里可以真實地模擬地震時的橫波和豎波，以測試結構的抗震程度。貧尼不是很懂造房子的事情，但我也知道這一行要出一個新結構，用一個新材料，那要做的測試是異常嚴格的，搞不好就是人命關天的事情啊。

而程序也要看什麼樣的程序了，像我們的程序，你要是真的那麼容易崩潰，別說崩潰了，一個小地方算錯了就可能是幾億的損失，不亞於一場地震啊！我們可能出錯嗎？怎麼可能？！我們的測試是三百六十五度無死角的！就羅列一下我們一段新代碼從編寫到使用中間的過程吧：

(1) write acceptance tests

(2) write integration tests

(3) write unit tests

(4) make unit tests pass

(5) make integration tests pass

(6) make acceptance tests pass

(7) make full test set pass

(8) run code in qa

(9) qa sign off

(10) run code in uat

(11) controller sign off

(12) deploy to prod

就算在production env 裡面出現了小bug, 做support的人都會第一時間給dev反饋，我們馬上就patch。做房子也有小瑕疵，比如燈吊得有點歪，用戶一發現，馬上fix.

我們application中一個新的feature，就算很小的改變，從開始做到最後用，少說也兩三個月，還是在我們做事特別迅捷高效的前提下。因為中間會有各種人，各種方式來測試，代碼的嚴謹是我們的bottom line. 樓主所說的程序出現致命的錯誤崩潰的狀況，幾乎不可能出現在一個完善的系統中。

啊從建築學的角度來說一個建築建成要經過層層的審核確保他不會垮掉.......而且建築是終身責任制出了事兒你就算七老八十了也還是要負責任當然會謹慎很多

另一方面講建築歷史遠比編程長很多所以技術方面比較成熟並不是一條路通到底有很多解決方法就像樹狀圖一樣所以逆推回來出錯的可能性也會減小

項目管理的理論是相通的，比如PMBOK的理論建築工程在用，在實踐；軟體工程也是。

所以這個問題是很多人都問過的。為啥軟體項目失敗的多，而建築項目相對比較少。

比如著名的一個例子是IBM的OS/360的開發。項目逾期，費用遠超預算，等等。

實際上80%以上的軟體項目從某種意義上說是失敗的。嚴格的在工期，預算範圍內完成初期要求的軟體項目少之又少。大量的存在逾期和超預算，質量不達標等問題。甚至完全搞砸了，做不出來或者做到後期發現構架搞錯了需要推翻重做的軟體項目也很多。

那麼為什麼同樣應用同一套理論的建築行業，與軟體行業相比失敗案例相對較少呢。個人覺得無外乎如下幾點。

1.技術的成熟性不同

軟體行業，或者說整個計算機行業歷史太短。和有著數千年歷史的建築行業相比還太不成熟。技術上不確定的因素或者說技術頻繁更迭造成的不確定因素多。

2.行業規範的成熟度不同

同樣是貫徹管理學的原則，建築工程往往有相對獨立的施工方和監理方，而且都需要相應的行業資質。而軟體行業的方法和規程集論層出不窮，什麼CMMI，ISO，UML，OO的名詞令人眼花繚亂。實際在開發中真正能將工程學規範貫徹好的企業寥寥無幾。而真正貫徹好了的企業則鮮有大的失敗

3.施工的可控程度不同

需求明確了，方案通過了，好咱施工吧。建築行業很多施工過程是看得見的易於監督的，而軟體行業的度量指標往往是針對文檔和代碼。房子地基打得好不好，內行能看個門道外行能看個熱鬧。代碼寫得好不好，舉個例子，當初豐田汽車出事兒，美國人找了嵌入式專家讀代碼。專家關小黑屋讀完代碼給出的結論是無法直接證明是程序原因造成的，但是程序沒有遵循汽車行業規範，有引發剎車問題的隱患。

說白了不說過程中的可控程度，就是東西擺在面前，不是專家都讀不懂，讀懂了也不敢下直接的結論。這樣的工程監控監管的難度可想而知。

10年軟體行業從業，設備研發/系統開發管理做下來的一點不成熟的心得。各位軟體工程學的大牛輕拍。

比喻是為了突出相似性，而不是完全一樣。

我們說「這個女生就像花兒一樣~」，是為了表達兩者都很漂亮，如果你用「一個是動物，一個是植物，怎麼能一樣呢？」來反駁，就是在耍流氓了。

作為設計建造類工程，建築和軟體還是有一些淵源的，當年Christopher Alexander提出建築學設計模式的概念被成功的應用到了軟體領域。對樓主關於「錯誤百出」的理解不認為是需求實現的錯誤，類似於要建一個煙囪，結果卻挖了一口井這樣的。暫理解為建築倒塌，軟體崩潰這樣的錯誤。

相比而言建築是一個古老的行業，幾乎是人類最早的技能之一，而軟體不過是近一百年的新興事物，兩者積累的經驗不在一個數量級上。軟體開發技術也在不斷的發展積累，相信以後會做的更好。

建築和軟體的存在環境差別很大，建築存在於自然，可觀測可感觸；而軟體存在於特定的設備中，只有運行時才能感覺的到，這種差別導致了受眾的巨大差異，隨便一個人都可以對一個建築做出這樣或者那樣的評價，但是一個軟體，如果沒有引導說明好多人甚至不知道該怎麼開始。可見用戶範圍差別很大的，能被測試的程度是不一樣的。

建築穩定性應該直接和根基及存在環境的穩定性（不怎麼變）相關，根基和環境要是頻繁變動，那建築的穩定性也是不堪一擊的，看看歷次大地震、颶風、海嘯，能挺住的建築有多少。軟體運行也依賴於不同的設備環境，同一個軟體運行的環境差別可能很大，在一個機器上運行正常表現完美，在另一個機器上可能藍屏重啟各種崩潰，不談存在環境的穩定性是沒有意義的。

如果以不倒塌不崩潰作為目標的話，建築貌似是遵循TDD（Test-Driven Development）的，你建或者不建地心引力就在那兒不增不減，底層如果跑偏的太厲害等不及上層就先崩塌了，而軟體開發環境大都是理想環境，大量具體的測試需要到使用的真實環境去。

綜上，軟體和建築是很不同的兩個領域，但彼此還是可以相互學習和借鑒許多方法經驗的

說個題主的錯誤，保證建築的可靠性的人是結構設計師，不是建築師！建築設計和結構設計是兩個部分！不要把我們結構的給歸到建築那塊去好不好…我會生氣的…

因為建房子有各種非常嚴格的標準，而且有相關部門進行把關，至於最後房子的質量，那就看綜合因素了。而且建不同的房子也有不同的標準，比如100層的樓房，那標準能和茅草房一樣嗎？

再來看程序，程序也有很多指標（有時候是明確的，有時候是比較大概的），但是，最主要的目標還是能用，就像房子要能住人一樣。和建房子一樣，不同的情況下，對程序的各項指標要求也是不一樣的，比如銀行系統，那對安全性，穩定性，準確性要求都是非常高的。但是一般的軟體，沒有涉及到很敏感的屬性（比如錢），那麼用起來舒服，漂亮點就是最重要的指標。

當然，也可以安100曾樓房的標準去建茅草房，也可以按銀行系統的標準去生產普通的軟體，但是，誰來投入這個成本呢？

怒答：

1.方案

建築工程項目中業主對自己項目的功能性都是很關心的（還有喪心病狂要美觀的），在與業主反覆博弈的過程中方案也會越來越完美。

2.施工圖

施工圖階段的深化設計會檢驗方案中的各種不合理並進行適當修改

3.校對審核

設計院內部的有經驗工程師各種看圖各種檢查

4.審圖

外審公司收了業主的錢再檢查一遍圖紙，這個有很認真也有敷衍一下的，不過大的問題一般都能看出來

5.施工階段

很多問題到了現場施工單位實際蓋樓的時候就給你發現了，再一次修正機會

6.很嚴肅地告訴大家，建築工程是終身責任制的，比如你設計的樓塌了就要檢查你設計有沒有問題，有問題的話不只是丟飯碗，還有坐牢風險

軟體畢竟是人在創造出來的工程。程序只需要運行ok，測試ok就行，那麼一般軟體bug有沒有？必須有，你賞人家幾十萬刀去查肯定能查出來，還不少。你看win7，chrome，mac它們還不是bug不斷...

而土木建築，是參照自然規律造出來的。人命關天，設計師必須根據千百年來經驗累累積到理論實踐得出的規範執行，謹小慎微地一點一點創造並驗證。規範都是對的(至少是安全的)，理論符合實際。

人可以計算出地震荷載，溫度荷載，風荷載多大什麼樣的結構合適多粗的鋼筋扛得住，但人能料想到別人會在什麼樣的環境下怎麼樣折騰什麼樣的電腦上的軟體么？

有一個沒有提到的是，一個土木工程，正常情況下(大地震泥石流什麼的沒辦法)，是必須不能「崩潰」的：必須經過彈性變形，到塑性變形再垮掉。這時你已經發現了這個「bug」，也要開始修補「bug」了，當然拆了重做一般更穩妥方便...

要睡了，想哪說哪，匿

又是耍流氓問題，你怎麼知道建築不是錯誤百出？

說到致命錯誤這個問題，首先是需求不同。

建築不能倒塌是默認的第一原則，其他原則都要讓步於這個原則。因為一倒就在也沒有以後了

如果某軟體的需求里有一條，絕不能崩潰，如果一崩潰這個軟體就得從世界上消失附帶N條人命和經濟損失。那麼這個軟體一定極其健壯，其出現致命錯誤的幾率，一般並不會比一般的建築倒塌的幾率更高。副作用就是要麼功能少要麼性能差要麼體驗搓要麼非常貴。

換句話說，都是需求和成本決定的，如果一個軟體每個月掛一次，每次帶來10萬經濟損失，一年不過100萬。但要是想把他做成10年掛一次的質量（比如軍工，航空，銀行等），就要多花幾千萬。就看用戶和投資人怎麼選了。

首先，這兩者的難度根本就沒在一個數量級，蓋房子看起來麻煩，實際上很多的方案和設計原則標準是定死的，在施工前，圖紙就定稿了，後期基本是按圖紙辦事。但是軟體是做不到這一步的，哪怕架構設計的再牛B，也需要工程師去一個字元一個字元的敲出來，不同的人思維方式不同，所以實現同一個功能的代碼也是不同的，這本身就缺少了一種約束力。

其次，兩者的容錯度不一樣，房子只不出大問題，是不會推倒重來的，但是軟體出現問題，測試通不過，那是無數次的輪迴啊，最後修補花的時間比開發的時間長多了。而且，軟體一小處的錯誤可是會導致全盤奔潰的。

第三，話語權的問題，軟體公司是乙方，話語權不強，但是房子乙方是設計院或房地產規劃公司，比較強勢。

不請自來…建築圖紙從設計院到施工方後，施工方的一群施工員就會進行圖紙會審，當施工員發現圖紙上有錯誤或覺得設計上有很坑爹的地方，就會反映回設計院，或打電話給結構工程師問，工程師就會自查。所以這樣bug就會比較少

這只是比喻，有一些類似，你不能說軟體就是建築

鐵道部蓋火車站，塌了還得了嗎？但售票網站翔一樣，沒事崩個幾天，你也就最多罵罵。

資金和重視程度的問題，畢竟軟體油水巨大，你懂的，資金自然不充足了，工作量和耗時也是不太能精確量化。而蓋房子的歷史都多悠久啦？預估工作量和時間比軟體精準的多。而且建築都是跟各種證掛鉤責任，出大bug好多相關人員要丟飯碗還要坐牢的，小bug漏個水裂個啥的事又不是少了。一般的軟體項目出大bug要坐牢的情況很少～除非涉及錢或直接經濟損失等。

沒有人會無緣無故去爆破一棟樓，哪怕那棟樓不設防，沒保安；但是一個沒有安全措施的伺服器會被各種玩弄。各種自然災害來了你就覺得的建築不安全了

所以這兩個行業都經常加班？摺疊我吧。。。

建築工程里用了什麼方法導致蓋出來的房子不像軟體工程那樣錯誤百出？

這個問題帶有強烈的偏見，而且不正確

一個真正的「摩天大樓」般的「程序」，必定是非常擼棒（Robust，擼了才會棒哦！）

當然了，正如會有「偷工減料的危樓」，當然也會有看起沒事，其實BUG一大堆的程序了。

舉幾個牛掰一點的例子，比如Windows和Linux，此兩大系統也都是「程序」，恩，你的電腦應該沒事吧？

比如android和IOS，其實都是linux的變型，也沒見現在的智能機，沒事就自動重啟然後報廢吧？

另外，程序寫完其實要做很多的測試，具體軟體測試方法_百度百科

我相信，應該不比建築要做的測試少很多吧？

或許有些就已經借鑒了建築學的方法

其實就是花多一點時間查bug了啦