可重用性是一個謬論 - UWE FRIEDRICHSEN
多年來,可重用性/可複用性是軟體架構設計中的一個聖盃。關於可重用軟體模組的討論在1970年代初得到了發展。例如,1974年史蒂文斯,邁爾斯和君士坦丁(Stevens,Myers和Constantine)撰寫的開創性的電腦科學論文“結構化設計”(Structured design)已經討論了將可重用性作為結構化設計的目標之一。
討論一直持續到今天。誠然,這個想法很有趣:我只建立了一個軟體模組,並且由於基本上沒有軟體的複製成本,所以我可以在任意多個地方免費使用它。投資一次,永遠收穫。多麼有效的槓桿!節省成本!
因此,毫不奇怪的是,幾代IT經理都要求可重用性是必不可少的設計目標,而作為他們的大祭司,作為回報的架構師則努力提供可重用性。隨著時間的流逝,對可重用性的渴望已變得獨立。在給定的環境下,沒有人再問過可重用性是否有意義。
從我在IT生涯中所看到的一切來看,可重用性從來沒有節省投資,我敢肯定,將來它也將永遠無法有效。
原因有多個方面:
首先,可重用性是一種深厚的工業信念。在物理世界中,可重用性在大多數情況下可以與標準化互換。標準化零件支援以較低的價格構建產品,並且可以輕鬆地在多個產品中重複使用。另一方面,在設計時考慮到可重用性的任何零件都可以成為標準化零件的候選人。
物理世界中可重用性/標準化的關鍵方面在於,隨著時間的推移,它有助於節省成本。您只需花費一次設計零件的時間即可。生產過程只需要設計和設定一次。所需的工具只需建立和安裝一次。之後,您可以製作所需數量的零件副本,而無需重複設計和設定投資。
這樣,可重用性有助於滿足工業市場的關鍵成功標準:以經濟高效的方式擴大規模。成本節省的很大一部分來自零件的生產,您可以生產很多零件,而不必一遍又一遍地設計和設定生產過程以及工具。
如果您以可以在不同上下文中(重複)使用的方式另外建立零件,則可以產生更大的數量,這有助於進一步分散設計和設定的固定成本,即零件變得更便宜
因此,在可重用零件建立房屋,橋樑,傢俱,電子裝置等的物理世界中,始終如一地追求可重用性是很有意義的。但是,將這種通過可重用性來節省成本的想法轉移到軟體開發中會遇到許多警告。
實施是設計的一部分而不是生產的一部分
第一個長期的誤解是,可以將編寫程式碼與建造房屋或組裝汽車相提並論。這個想法是,可以將軟體體系結構和設計工作與設計汽車或房屋,並編寫程式碼來執行計劃(即組裝最終產品)進行比較。
不幸的是,這種看法是完全錯誤的。軟體開發的最終產品是可執行程式。我們通常通過編譯原始碼4來建立它。換句話說:IT可能擁有60多年以來可以想象到的最高效的生產流程,因為它是如此高效,以至於我們通常完全忘記了它。
今天,這種生產過程通常是CI / CD流程中的一個步驟,但是它並沒有改變我們在沒有任何人工干預的情況下以極其有效的方式構建產品的事實。
另一方面,編寫程式碼可以完成設計。產品設計僅在編寫最後一行原始碼之後才能完成。編寫程式碼就像新增汽車設計的詳細資訊,設計形狀,內部設計,動力傳輸等的詳細資訊一樣,這是生產汽車之前需要完成的所有工作。生產實際產品時,從程式碼上執行的程式在時間,成本和工作量方面都是可以忽略的。
編寫程式碼即可完成設計。 從完成的設計中構建產品只是發出命令(與編寫程式碼無關)。 |
因此,所有將編寫程式碼與組裝汽車或蓋房相比較的隱喻都是錯誤的。
這也意味著從物理世界得出的假設被打破了,即通過使用可重複使用的零件,我們可以在生產過程中節省大量資金。與任何物理領域相比,IT的生產過程已經令人難以置信地便宜。此外,我們可以以零成本生產零件的許多副本:這稱為複製命令。
因此,基於物理世界中可重用性價值的所有考慮因素都不適用於IT,因為軟體開發中的可重用性無助於在生產過程中節省成本。
IT固有的缺乏標準化
通過設計過程中的可重用性,這仍然留有提高效率的空間。再次(誤用)汽車的隱喻:如今,許多汽車製造商使用平臺策略,即,他們在汽車設計中重複使用了許多標準化的基礎部件。例如,他們不會為他們設計的每個新模型從頭開始設計引擎或底盤,而是從平臺上重複使用引擎或底盤,併為特定模型單獨設計零件進行補充。
雖然這種再次使用零件的平臺方法主要是針對節省生產方面的成本(這與IT無關,正如我們在上一節中所看到的),但它也可能有助於減少設計過程中的時間,成本和工作量。
我們可以將這種思想應用於軟體開發:在設計中可以使用的可重用部分越多,即軟體開發過程,可以節省的時間,成本和精力就越多。
這是IT另一個特殊之處。
弗雷德·布魯克(Fred Brook)在其著名的論文“沒有靈丹妙藥” [url=https://www.ufried.com/blog/reusability_fallacy_1/#fn:5]5[/url]中解釋了軟體開發中必不可少和偶然的複雜性。他列出的基本複雜性的驅動因素之一是“複雜性”:
軟體實體的大小可能比任何其他人工構造的都要複雜,因為沒有兩個部分是相同的(至少在宣告級別之上)。如果是這樣,我們將兩個相似的部分合為一個子例程,即開啟或關閉。在這方面,軟體系統與計算機,建築物或汽車有著千絲萬縷的區別。[…]同樣,軟體實體的擴充套件不僅僅是重複相同的元素,而且尺寸更大。它必然會增加不同元素的數量。 |
首先,布魯克斯顯然拒絕了這樣的想法,即我們可以按照與我們通過多次佈置相同型別的磚塊來設計牆的方式相同的方式,從一組更高階別的標準化構件中設計軟體解決方案。我們使用的每個部分都會與其他所有部分不同。
然而,儘管使用標準化的構建塊作為依據,布魯克斯仍然留有重用的餘地:他指出我們解決方案中的每個部分都會有所不同,但在更高層次的環境中,我們可能會多次使用該部分。遵循這個想法,我們重用了較低階別的功能來支援較高階別的功能。
剩下的可重用性
在這篇文章中,我試圖解構一部分可重用性謬論:這種謬論是,通過使用標準化的可重用部件,我們可以從更高效的生產過程中節省很多錢。軟體開發與設計有關。僅在編寫最後一行程式碼之後,設計才完成。
實際的生產過程(即建立可執行程式)是如此高效且廉價,以至於沒有什麼可節省的。因此,所有從物理世界中獲取概念並將其應用於軟體開發的可重用性方法都行不通。
相關文章
- 認知謬論:什麼是弗雷德金悖論
- 認知謬論:什麼是吉布森定律?
- 認知謬論:什麼是特威曼定律?
- 認知謬論:什麼是舍基原則?
- 認知謬論:什麼是維度詛咒
- 為什麼程式碼重用仍然是一個安全噩夢
- 認知謬論:維特根斯坦的尺子
- 如何避免遊戲平衡中的“滅霸謬論”?遊戲
- 常見的讓人大吃一驚的八種邏輯謬論 - markmanson
- 一個詭異的"可見性"問題
- 人工智慧下一個前沿:可解釋性人工智慧
- 增強 React 列表渲染:乾淨且可重用的模式React模式
- 使用 Spring Boot 構建可重用的模擬模組Spring Boot
- 程式碼質量第 2 層 - 可重用的程式碼
- 重用或複用會導致耦合,微服務是寧可重複也不耦合 - Victor Rentea微服務
- 一個技術總監的忠告:精通那麼多技術,你為何還是受不到重用?
- 分散式計算的八個謬誤 - Ably分散式
- 分析師談如何避免遊戲平衡中的“滅霸謬論”遊戲
- Volatile可見性分析(一)
- 現在是做一個站長部落格好還是做一個站長論壇好?
- UA MATH523A 實分析3 積分理論例題 判斷函式可積性的一個題目H5函式
- WPF中的命令模式:打造清晰、可重用的程式碼利器模式
- 什麼是認知謬誤中的“相對困境”?
- 論Java訪問許可權控制的重要性Java訪問許可權
- 認知謬論:為99%的程式設計師代言 - a16z程式設計師
- 效能優化常見謬論——面試別再這樣答了優化面試
- Java 抽象類與方法:實現安全性與程式碼重用Java抽象
- 一步步瞭解執行緒池之可重用固定執行緒數-FixedThreadPool執行緒thread
- 併發bug之源(一)-可見性
- 字型的粗細的屬性是用哪一個?它有哪些屬性值?
- 幽默:可組合性是軟體的複利
- 重用其他程式庫
- 爭論不休的一個話題:金額到底是用Long還是BigDecimal?Decimal
- 資料科學的下一個「超能力」:模型可解釋性資料科學模型
- 轉行學IT沒前途?一個培訓班出來的,憑什麼受到重用?
- 如何在 SAP BTP 平臺上重用另一個已經開發好的 service
- 論一個遊戲角色是怎麼誕生的——原畫篇遊戲
- KDD 2019論文解讀:多分類下的模型可解釋性模型