軟體開發不能用建築開發來比喻

標籤：

　　多年以來，軟體行業一直在使用一種類比，即以建築行業來做參考和比喻。這種比較在軟體語言裡隨處可見，比如架構(architecture)、地基(foundation)、建造者(constructor)、項目(project)、施工規範(building code)等。這些說法是如此之流行，以至於影響到了我們對軟體開發的理解。不幸的是，這種比喻從根本上來說是不恰當的，它的缺陷已經把我們引向了一些錯誤的道路。

　　

 

　　在建築行業，很多重點都放在可預測性上——預先把需求確定清楚，並且縮減成本。這些都是成熟行業的標誌。而當我們把這些重點應用到軟體上時，問題就來了!

　　經驗法則、施工規範和原材料

　　現代建築可以追根溯源到幾百甚至幾千年以前——就看你把起點放在哪兒。經過所有曆史的沉澱，大量的專業知識凝結在了經驗法則裡，比如：

　　在大部分地方，每平方英尺的建築成本是一個眾人皆知的常數。舉個例子，我們最近在家裡做了一些翻修，行業裡的朋友就提醒我們說：在渥太華，典型的翻修成本在每平方英尺$35到$50之間。他們說得非常准!

　　對水泥樓板深度的一個比較好的評估是，相當於它的無支周長的1/180。

　　另一方面，軟體最多也就70年的曆史。它的經驗法則還沒有像建築那般牢靠的曆史，尚不足以保障堅不可摧的應用。

　　經驗法則最終會被編寫成施工規範而固化下來。造房子的時候，施工規範決定了從壁骨間距，到牆上和屋頂絕緣物數量的方方面面。這些規範意味著所有的房子都達到了最低要求標準，極大地提升了成本的可預測性。

　　這些施工規範的存在，主要是因為建築材料(木頭、鋼鐵等)和工具(鐵鎚、鋸子等)的種類是有限的。這些材料的屬性和故障模型都是可預見的。能與特定材料配合使用的工具為數不多，也已被充分認知。當然，在建築行業，材料和工具也在持續進化，但其進化速度遠遠比不上軟體。

　　在軟體行業，跟上一系列新材料和工具的難度要大得多!程式設計語言、程式庫、支援工具每年都會冒出來，並且不斷進化。內容也在不斷豐富。即使我們專註於現有的語言和庫，為了制定標準規範而去探索所有的細節並且體會個中的細微差別，這也需要花上幾年的功夫。

　　正是因為易懂、穩定的材料和工具，才有了制定建築規範的可能。而軟體世界的不穩定性，決定了我們在這個領域永遠也不會有“施工規範”。

　　在軟體行業不存在有用的經驗法則或施工規範!

　　物理約束和穩定的需求

　　大樓、橋樑和其他建築工事都受著物理約束的支配。依據使用的材料，這些約束決定了一個建築物的尺寸、形狀和用途。舉例來說，木結構建築受限於4~6層的高度;橋樑的跨度受限於使用的材料，以及這些材料相關的物理屬性。

　　大樓和橋樑的建築代表了一個問題域，已被人世代研究和實驗。因此，客戶需要問的問題都是可預見的，答案的範圍也是有約束的。

　　建築設計必須適應現場和功能的約束。想象一下，把辦公樓建成圍繞單點旋轉的陀螺儀那樣，儘管很有趣，但它在物理上不切實際，也無法滿足功能上的需求。在修築橋樑或公路時，依據需要承受的車輛類型和尺寸，都有清晰的標準去遵循。

　　而軟體並不受制於類似的約束。如果客戶真的想要一個陀螺儀那樣的東西，我們很可能可以交付。我們需要支援的使用者類型以及用途，與建築比起來要寬泛得多!

　　大樓一旦開建，地基都打好了，你就不能輕易改變尺寸或現場位置。大樓的內部機構一旦開工建設，你就不能隨意決定新增一個電梯井或者加一個側翼。修建橋樑時，一旦橋墩澆築好了，你就不能因為客戶選錯了地方而把它們移動20米。(好吧，你能，只不過在此之前的工作都白費了，你需要從頭再來!)

　　而對於軟體來說，我們幾乎可以做我們想要的任何改動，簡單也好，複雜也罷，比如把支援的使用者數從100提高到1000，改變產品方向(Yelp原本只是一個向朋友推薦餐廳、醫生等資訊的工具。後來才演變成了一個評論網站)，換一種程式設計語言(我曾經參與過從Java變到.NET又變回Java的項目)——所有這些變動比從頭再來的成本要小得多!

　　譯者註：Yelp是美國著名商戶點評網站，創立於2004年，囊括各地餐館、購物中心、酒店、旅遊等領域的商戶，使用者可以在Yelp網站中給商戶打分，提交評論，交流購物體驗等。

　　正因為我們在軟體上有極大的靈活性，我們也能夠在開發的全過程中接受需求的改變。開發早期階段被挖掘出來的需求，在它們被最終實現之前往往會變動好幾次。

　　在建築的世界裡，設計師把一套設計圖交給建築工人的時候，還能有相當的信心他們可以正確理解。儘管還是會有一些關於變動的需求和溝通，但變動的程度不可與軟體同日而語。反觀軟體世界，我們並沒有有效方式(即使是UML)來做到給開發人員交付了設計圖之後就可以甩手不管。取而代之的是，我們要在客戶和軟體開發人員之間持續不斷地進行一系列的會談。

　　軟體比建築更傾向於接受大幅度的改動!

　　人員

　　在建築行業，工人通常被認為是可以交換和替換的。存在這樣的假設：在造一間房子的時候，如果你把木匠換掉，結果通常是一樣的。

　　這在軟體世界裡可不是這麼回事!因為工具(程式設計語言和庫)和問題領域存在的複雜性以及變數，開發人員、商務分析師、測試人員、使用者體驗設計師等人是不能隨處流動的。

　　那些認為軟體與建築有關聯的人想當然地以為，人員是可以替換和交換的。但那與事實相去甚遠!軟體的所有實質內容都是各團隊裡的人構建出來的，如果你把一個團隊成員替換掉，這會在以下三個主要方面對團隊帶來影響：

　　他們會失去只有那位前團隊成員才瞭解的知識;

　　他們必須培訓新團隊成員：他們在做什麼，以及最新的進展;

　　他們必須花時間與新人建立起有效工作關係。

　　結果是，替換或增加一個新人把整個團隊的進度拖慢了至少3~4個月。從個案來看，新的團隊成員在完全發揮效力之前常常花費比那更長的時間。儘管建築行業在人員變動時也會遭受進度拖延的痛苦，但其痛苦程度是遠遠不及軟體項目的。

　　Fred Brooks(《人月神話》的作者)有一句名言：“向進度落後的項目中增加人手，只會使進度更加落後。”40多年過去了，這句話仍然有效!

　　結論

　　那些經常用來描述軟體的建築隱喻是錯誤的。可悲的是，因為有了這層暗示，我們把很多重點放在了錯誤的地方：

　　力求把需求預先定義清楚，而不是接受：變化才是常態;

　　強調架構和架構師的重要性，而不是接受：軟體是可適應的，可由團隊裡的任何人來改變;

　　假設人員是可替換的，並且時間問題可以通過增加人手來解決，而不是接受：每個人都是獨特的;

　　追求可預測性，而不是接受：我們的領域還沒有被很好地認知。

　　軟體與建築絕無關係!

　　我們不是在建造，而是在探索!

　　我們在客戶的問題空間裡探索。我們正在提出新的想法，而它們剛好用代碼來表達。讓我們丟棄老的建築隱喻吧，因為它們會使我們通向未來之路的地基崩裂坍塌。持這個觀點的人可不止我一個哦!

軟體開發不能用建築開發來比喻