> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 沃斯定律

> 沃斯定律提醒我們，軟體變慢速度常快於硬體變快。它要求團隊把效能預算與複雜度控制納入日常治理，而非等上線後補救。

<Info>
  **類別**：定律<br />
  **類型**：軟體效能與複雜度啟發式<br />
  **來源**：通常歸於電腦科學家尼克勞斯・沃斯（1990 年代中期）<br />
  **別名**：軟體膨脹原則
</Info>

<Note>
  **快速回答** — **沃斯定律**（Wirth's Law）指出：軟體變慢的速度，常快於硬體變快。它揭示的核心不是晶片不夠快，而是複雜度治理失敗。有效做法是把延遲預算、記憶體預算與依賴上限設為硬性產品要求。
</Note>

## 什麼是沃斯定律？

**沃斯定律**（Wirth's Law）是一條工程警示：硬體進步不會自動轉化為使用者體感速度，因為軟體層的抽象與功能膨脹可能更快吃掉效能紅利。這也是為何新裝置不一定更順暢。

> 效能紅利不會自動抵達使用者；要嘛被工程化兌現，要嘛被複雜度吞噬。

它可與 [摩爾定律](/zh-hant/laws/moores-law)（硬體能力成長）、[布魯克斯定律](/zh-hant/laws/brookss-law)（協作規模帶來協調成本）和 [康威定律](/zh-hant/laws/conways-law)（組織結構映射系統結構）併讀，也與 [霍夫施塔特定律](/zh-hant/laws/hofstadters-law) 互補：複雜度成本往往被低估。

### 沃斯定律的三層理解

* **入門**：換更快硬體，不代表軟體體感必然更快。
* **實踐者**：建立明確效能預算，超預算功能必須先證明價值。
* **進階**：把架構、激勵與發布門檻對齊，讓複雜度增速低於容量增速。

## 起源

此說法通常歸於電腦科學家 **尼克勞斯・沃斯**，他長期強調精簡軟體與語言／工具設計紀律。1990 年代硬體快速進步時，業界卻反覆觀察到日常軟體體感未同步提升，主因正是抽象層與功能層持續疊加。

這一定律歷久不衰，是因為它準確描述了組織模式：團隊通常為可見功能被獎勵，而效能成本被外部化給使用者與未來維護者。

## 核心要點

沃斯定律本質上是軟體經濟學與治理問題。

<Steps>
  <Step title="複雜度會默默消耗容量">
    每增加一層框架、依賴或整合，都可能在啟動、執行和故障路徑上增加隱性開銷。
  </Step>

  <Step title="預設激勵偏向功能堆疊">
    團隊較易因新增功能被肯定，而較少因維持效能餘裕被肯定。
  </Step>

  <Step title="效能負債具複利效應">
    每次小幅回退長期累積，會演變成明顯延遲和基礎設施成本壓力。
  </Step>

  <Step title="預算機制讓取捨可執行">
    將效能預算寫入發版標準，速度才會成為可審計的決策條件。
  </Step>
</Steps>

## 應用場景

把效能治理從事後救火前移到設計與評審流程。

<CardGroup cols={2}>
  <Card title="Web 產品" icon="globe">
    在 CI 持續監控包體與互動延遲預算，超閾值即阻擋合併。
  </Card>

  <Card title="行動應用" icon="mobile-screen-button">
    以中階裝置的冷啟動與記憶體壓力作為主要驗收基準，不只看旗艦機。
  </Card>

  <Card title="後端服務" icon="server">
    控制依賴擴張並監測尾延遲，避免版本演進中可靠性逐步下滑。
  </Card>

  <Card title="工程管理" icon="users-gear">
    把效能回退納入路線圖成本，終止「硬體會兜底」的默認假設。
  </Card>
</CardGroup>

## 經典案例

公開 Web 長期遙測顯示，平均頁面複雜度與資源體積顯著增長，JavaScript 與媒體載荷提高了傳輸與執行成本。在許多團隊中，這些增量抵消了部分硬體與網路進步帶來的紅利，尤其在中階手機更明顯。實務常用可量化指標是 Core Web Vitals（如 LCP、INP）；若缺乏預算門檻，功能密集發布後常出現回退。以沃斯定律解讀，重點很直接：效能不是自然產物，而是治理結果。

## 邊界與失效場景

沃斯定律描述的是常見趨勢，並非反對所有抽象化。

**邊界一：工具鏈進步可扭轉趨勢**\
編譯器最佳化、執行時改進與架構簡化都能有效回收效能。

**邊界二：部分效能成本具正當價值**\
安全性、可及性與正確性提升，可能提高計算開銷但改善整體品質。

**常見誤用**：引用此定律全面否定現代化改造，而不做價值與延遲的明確權衡。

## 常見誤區

正確理解可避免「盲目追新」與「盲目守舊」兩端擺盪。

<AccordionGroup>
  <Accordion title="誤區：它代表現代框架都不好">
    **事實**：問題不在框架存在，而在是否持續度量並治理其開銷。
  </Accordion>

  <Accordion title="誤區：硬體升級已經沒有意義">
    **事實**：硬體進步仍重要，只是若治理不足，增益會被軟體側吃掉。
  </Accordion>

  <Accordion title="誤區：效能可以最後再補">
    **事實**：長期效能表現多在早期架構與預算決策時就已被決定。
  </Accordion>
</AccordionGroup>

## 相關概念

這些概念可協助把沃斯定律落地為工程制度。

<CardGroup cols={3}>
  <Card title="摩爾定律" icon="microchip" href="/zh-hant/laws/moores-law">
    硬體能力成長提供機會，但不保證使用者體感同步提升。
  </Card>

  <Card title="康威定律" icon="diagram-project" href="/zh-hant/laws/conways-law">
    組織溝通結構會塑造系統結構，也會塑造效能負債形態。
  </Card>

  <Card title="布魯克斯定律" icon="people-group" href="/zh-hant/laws/brookss-law">
    協調成本上升會推高複雜度，進一步拖慢品質與交付效率。
  </Card>
</CardGroup>

## 一句話總結

<Tip>
  硬體給的是效能預算，軟體治理決定這份預算是回到使用者，還是被複雜度吃掉。
</Tip>