多年以來，軟體行業一直在使用一種模擬，即以建築來做參考和比喻。這種比較在軟體語言裡隨處可見，比如架構（architecture）、地基（foundation）、建造者（constructor）、專案（project）、施工規範（building code）等。這些說法是如此之流行，以至於影響到了我們對軟體開發的理解。不幸的是，這種比喻從根本上來說是不恰當的，它的缺陷已經把我們引向了一些錯誤的道路。
在建築行業，很多重點都放在可**性上——預先把需求確定清楚，並且縮減成本。這些都是成熟行業的標誌。而當我們把這些重點應用到軟體上時，問題就來了！
經驗法則、施工規範和原材料
現代建築可以追根溯源到幾百甚至幾千年以前——就看你把起點放在哪兒。經過所有歷史的沉澱，大量的專業知識凝結在了經驗法則裡，比如：
在大部分地方，每平方英呎的建築成本是乙個眾人皆知的常數。舉個例子，我們最近在家裡做了一些翻修，行業裡的朋友就提醒我們說：在渥太華，典型的翻修成本在每平方英呎$35到$50之間。他們說得非常準！
對水泥樓板深度的乙個比較好的評估是，相當於它的無支周長的1/180。
另一方面，軟體最多也就70年的歷史。它的經驗法則還沒有像建築那般牢靠的歷史，尚不足以保障堅不可摧的應用。
經驗法則最終會被編寫成施工規範而固化下來。造房子的時候，施工規範決定了從壁骨間距，到牆上和屋頂絕緣物數量的方方面面。這些規範意味著所有的房子都達到了最低要求標準，極大地提公升了成本的可**性。
這些施工規範的存在，主要是因為建築材料（木頭、鋼鐵等）和工具（鐵鎚、鋸子等）的種類是有限的。這些材料的屬性和故障模型都是可預見的。能與特定材料配合使用的工具為數不多，也已被充分認知。當然，在建築行業，材料和工具也在持續進化，但其進化速度遠遠比不上軟體。
在軟體行業，跟上一系列新材料和工具的難度要大得多！程式語言、程式庫、支援工具每年都會冒出來，並且不斷進化。內容也在不斷豐富。即使我們專注於現有的語言和庫，為了制定標準規範而去探索所有的細節並且體會個中的細微差別，這也需要花上幾年的功夫。
正是因為易懂、穩定的材料和工具，才有了制定建築規範的可能。而軟體世界的不穩定性，決定了我們在這個領域永遠也不會有「施工規範」。
在軟體行業不存在有用的經驗法則或施工規範！
物理約束和穩定的需求
大樓、橋梁和其他建築工事都受著物理約束的支配。依據使用的材料，這些約束決定了乙個建築物的尺寸、形狀和用途。舉例來說，木結構建築受限於4~6層的高度；橋梁的跨度受限於使用的材料，以及這些材料相關的物理屬性。
大樓和橋梁的建築代表了乙個問題域，已被人世代研究和試驗。因此，客戶需要問的問題都是可預見的，答案的範圍也是有約束的。
建築設計必須適應現場和功能的約束。想象一下，把辦公樓建成圍繞單點旋轉的陀螺儀那樣，儘管很有趣，但它在物理上不切實際，也無法滿足功能上的需求。在修築橋梁或公路時，依據需要承受的車輛型別和尺寸，都有清晰的標準去遵循。
而軟體並不受制於類似的約束。如果客戶真的想要乙個陀螺儀那樣的東西，我們很可能可以交付。我們需要支援的使用者型別以及用途，與建築比起來要寬泛得多！
大樓一旦開建，地基都打好了，你就不能輕易改變尺寸或現場位置。大樓的內部機構一旦開工建設，你就不能隨意決定新增乙個電梯井或者加乙個側翼。修建橋梁時，一旦橋墩澆築好了，你就不能因為客戶選錯了地方而把它們移動20公尺。（好吧，你能，只不過在此之前的工作都白費了，你需要從頭再來！）
正因為我們在軟體上有極大的靈活性，我們也能夠在開發的全過程中接受需求的改變。開發早期階段被挖掘出來的需求，在它們被最終實現之前往往會變動好幾次。
在建築的世界裡，設計師把一套設計圖交給建築工人的時候，還能有相當的信心他們可以正確理解。儘管還是會有一些關於變動的需求和溝通，但變動的程度不可與軟體同日而語。反觀軟體世界，我們並沒有有效的方式（即使是uml）來做到給開發者交付了設計圖之後就可以甩手不管。取而代之的是，我們要在客戶和軟體開發者之間持續不斷地進行一系列的會談。
軟體比建築更傾向於接受大幅度的改動！
人員
在建築行業，工人通常被認為是可以交換和替換的。存在這樣的假設：在造一間房子的時候，如果你把木匠換掉，結果通常是一樣的。
這在軟體世界裡可不是這麼回事！因為工具（程式語言和庫）和問題領域存在的複雜性以及變數，開發者、業務分析師、測試人員、使用者體驗設計師等人是不能隨處流動的。
那些認為軟體與建築有關聯的人想當然地以為，人員是可以替換和交換的。但那與事實相去甚遠！軟體的所有實質內容都是各團隊裡的人構建出來的，如果你把乙個團隊成員替換掉，這會在以下三個主要方面對團隊帶來影響：
他們會失去只有那位前團隊成員才了解的知識；
他們必須培訓新團隊成員：他們在做什麼，以及最新的進展；
他們必須花時間與新人建立起有效的工作關係。
結果是，替換或增加乙個新人把整個團隊的進度拖慢了至少3~4個月。從個案來看，新的團隊成員在完全發揮效力之前常常花費比那更長的時間。儘管建築行業在人員變動時也會遭受進度拖延的痛苦，但其痛苦程度是遠遠不及軟體專案的。
fred brooks（《人月神話》的作者）有一句名言：「向進度落後的專案中增加人手，只會使進度更加落後。」40多年過去了，這句話仍然有效！
結論
那些經常用來描述軟體的建築隱喻是錯誤的。可悲的是，因為有了這層暗示，我們把很多重點放在了錯誤的地方：
力求把需求預先定義清楚，而不是接受：變化才是常態；
強調架構和架構師的重要性，而不是接受：軟體是可適應的，可由團隊裡的任何人來改變；
假設人員是可替換的，並且時間問題可以通過增加人手來解決，而不是接受：每個人都是獨特的；
追求可**性，而不是接受：我們的領域還沒有被很好地認知。
軟體與建築絕無關係！
我們不是在建造，而是在探索！
我們在客戶的問題空間裡探索。我們正在提出新的想法，而它們剛好用**來表達。讓我們丟棄老的建築隱喻吧，因為它們會使我們通向未來之路的地基崩裂坍塌。持這個觀點的人可不止我乙個哦。
軟體開發不可與建築模擬
多年以來，軟體行業一直在使用一種模擬，即以建築來做參考和比喻。這種比較在軟體語言裡隨處可見，比如架構 architecture 地基 foundation 建造者 constructor 專案 project 施工規範 building code 等。這些說法是如此之流行，以至於影響到了我們對軟體開...
軟體開發 不可能完成的任務？ 收藏
1998年7月6日，香港新機場赤角正式開通運營。這個耗資200億美元的建築專案終於可以讓人喘一口氣了。然而，當新機場開通運營之時，令人窘迫的問題出現了 電子訊號顯示了錯誤的資訊，系統被迫關閉，行李不見了，客貨運擱淺不前。200億美元複雜的建築結構的確是有史以來全球最大的建築專案之一。在專案中，半個世...
一次軟體開發不問技術的面試
今天早上面試了一家公司，武漢廣圖科技 大體說下面試的情況吧。以前不喜歡寫這類的東西，現在自己在找工作，也會遇到不了解的公司，自己也希望能在網上搜尋到相關資訊，幫助自己了解所應聘的公司，所以今天也把面試中遇到的情況寫下來，希望能給和我遇到相同情況的小夥伴乙個參考資訊吧。首先我面試的公司位址在武大科技園...