軟件開發不可與建筑類比
  • 艾特網絡傳媒
  • 日期: 2016-06-12
  • 分類: 行業洞察
  • 閱讀量: 89

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

     在建筑行業,很多重點都放在可預測性上——預先把需求確定清楚,并且縮減成本。這些都是成熟行業的標志。而當我們把這些重點應用到軟件上時,問題就來了!
 
     經驗法則、施工規范和原材料
 
      現代建筑可以追根溯源到幾百甚至幾千年以前——就看你把起點放在哪兒。經過所有歷史的沉淀,大量的專業知識凝結在了經驗法則里,比如:
 
l  在大部分地方,每平方英尺的建筑成本是一個眾人皆知的常數。舉個例子,我們最近在家里做了一些翻修,行業里的朋友就提醒我們說:在渥太華,典型的翻修成本在每平方英尺$35到$50之間。他們說得非常準!
 
l  對水泥樓板深度的一個比較好的評估是,相當于它的無支周長的1/180。
 
另一方面,軟件最多也就70年的歷史。它的經驗法則還沒有像建筑那般牢靠的歷史,尚不足以保障堅不可摧的應用。
 
經驗法則最終會被編寫成施工規范而固化下來。造房子的時候,施工規范決定了從壁骨間距,到墻上和屋頂絕緣物數量的方方面面。這些規范意味著所有的房子都達到了最低要求標準,極大地提升了成本的可預測性。
 
這些施工規范的存在,主要是因為建筑材料(木頭、鋼鐵等)和工具(鐵錘、鋸子等)的種類是有限的。這些材料的屬性和故障模型都是可預見的。能與特定材料配合使用的工具為數不多,也已被充分認知。當然,在建筑行業,材料和工具也在持續進化,但其進化速度遠遠比不上軟件。
 
在軟件行業,跟上一系列新材料和工具的難度要大得多!編程語言、程序庫、支持工具每年都會冒出來,并且不斷進化。內容也在不斷豐富。即使我們專注于現有的語言和庫,為了制定標準規范而去探索所有的細節并且體會個中的細微差別,這也需要花上幾年的功夫。
 
正是因為易懂、穩定的材料和工具,才有了制定建筑規范的可能。而軟件世界的不穩定性,決定了我們在這個領域永遠也不會有“施工規范”。
 
在軟件行業不存在有用的經驗法則或施工規范!
 
物理約束和穩定的需求
 
大樓、橋梁和其他建筑工事都受著物理約束的支配。依據使用的材料,這些約束決定了一個建筑物的尺寸、形狀和用途。舉例來說,木結構建筑受限于4~6層的高度;橋梁的跨度受限于使用的材料,以及這些材料相關的物理屬性。
 
大樓和橋梁的建筑代表了一個問題域,已被人世代研究和試驗。因此,客戶需要問的問題都是可預見的,答案的范圍也是有約束的。
 
建筑設計必須適應現場和功能的約束。想象一下,把辦公樓建成圍繞單點旋轉的陀螺儀那樣,盡管很有趣,但它在物理上不切實際,也無法滿足功能上的需求。在修筑橋梁或公路時,依據需要承受的車輛類型和尺寸,都有清晰的標準去遵循。
 
而軟件并不受制于類似的約束。如果客戶真的想要一個陀螺儀那樣的東西,我們很可能可以交付。我們需要支持的用戶類型以及用途,與建筑比起來要寬泛得多!
 
大樓一旦開建,地基都打好了,你就不能輕易改變尺寸或現場位置。大樓的內部機構一旦開工建設,你就不能隨意決定新增一個電梯井或者加一個側翼。修建橋梁時,一旦橋墩澆筑好了,你就不能因為客戶選錯了地方而把它們移動20米。(好吧,你能,只不過在此之前的工作都白費了,你需要從頭再來?。?/div>
 
而對于軟件來說,我們幾乎可以做我們想要的任何改動,簡單也好,復雜也罷,比如把支持的用戶數從100提高到1000,改變產品方向(Yelp原本只是一個向朋友推薦餐廳、醫生等信息的工具。后來才演變成了一個評論網站),換一種編程語言(我曾經參與過從Java變到.NET又變回Java的項目)——所有這些變動比從頭再來的成本要小得多!
 
譯者注:Yelp是美國著名商戶點評網站,創立于2004年,囊括各地餐館、購物中心、酒店、旅游等領域的商戶,用戶可以在Yelp網站中給商戶打分,提交評論,交流購物體驗等。
 
正因為我們在軟件上有極大的靈活性,我們也能夠在開發的全過程中接受需求的改變??⒃縉誚錐偽煌誥虺隼吹男棖?,在它們被最終實現之前往往會變動好幾次。
 
在建筑的世界里,設計師把一套設計圖交給建筑工人的時候,還能有相當的信心他們可以正確理解。盡管還是會有一些關于變動的需求和溝通,但變動的程度不可與軟件同日而語。反觀軟件世界,我們并沒有有效的方式(即使是UML)來做到給開發者交付了設計圖之后就可以甩手不管。取而代之的是,我們要在客戶和軟件開發者之間持續不斷地進行一系列的會談。
 
軟件比建筑更傾向于接受大幅度的改動!
 
人員
 
在建筑行業,工人通常被認為是可以交換和替換的。存在這樣的假設:在造一間房子的時候,如果你把木匠換掉,結果通常是一樣的。
 
這在軟件世界里可不是這么回事!因為工具(編程語言和庫)和問題領域存在的復雜性以及變數,開發者、業務分析師、測試人員、用戶體驗設計師等人是不能隨處流動的。
 
那些認為軟件與建筑有關聯的人想當然地以為,人員是可以替換和交換的。但那與事實相去甚遠!軟件的所有實質內容都是各團隊里的人構建出來的,如果你把一個團隊成員替換掉,這會在以下三個主要方面對團隊帶來影響:
 
l  他們會失去只有那位前團隊成員才了解的知識;
 
l  他們必須培訓新團隊成員:他們在做什么,以及最新的進展;
 
l  他們必須花時間與新人建立起有效的工作關系。
 
結果是,替換或增加一個新人把整個團隊的進度拖慢了至少3~4個月。從個案來看,新的團隊成員在完全發揮效力之前常?;ǚ馴饒歉さ氖奔?。盡管建筑行業在人員變動時也會遭受進度拖延的痛苦,但其痛苦程度是遠遠不及軟件項目的。
 
Fred Brooks(《人月神話》的作者)有一句名言:“向進度落后的項目中增加人手,只會使進度更加落后。”40多年過去了,這句話仍然有效!
 
結論
 
那些經常用來描述軟件的建筑隱喻是錯誤的??殺氖?,因為有了這層暗示,我們把很多重點放在了錯誤的地方:
 
l  力求把需求預先定義清楚,而不是接受:變化才是常態;
 
l  強調架構和架構師的重要性,而不是接受:軟件是可適應的,可由團隊里的任何人來改變;
 
l  假設人員是可替換的,并且時間問題可以通過增加人手來解決,而不是接受:每個人都是獨特的;
 
l  追求可預測性,而不是接受:我們的領域還沒有被很好地認知。
 
軟件與建筑絕無關系!
 
我們不是在建造,而是在探索!