三層架構設計思維（上）：為什麼你的試算表需要分層？

你有沒有遇過那種「大雜燴」式的試算表？

原始資料、計算公式、要給老闆看的圖表，全部塞在同一個畫面裡。這種表通常有一個特性：它是活的，而且脾氣很差。 稍微改一個數字，三個公式就報錯；刪掉一列，圖表直接消失。最後，除了你自己，沒人敢動這張表，甚至連你自己過了一週後，也要看半天才能想起邏輯。

這通常不是你的試算表技巧不好，而是**「架構」**需要稍微整隊了。

為什麼要分層？

如果不分層，我們常會遇到這些令人崩潰的時刻：

• 除錯像在找針：數字不對時，你得在密密麻麻的格子裡翻找，到底是原始資料打錯，還是公式寫歪了。
• 牽一髮動全身：原本只是想加一欄備註，結果後面的計算範圍全部跑掉。
• 協作時的尷尬：同事幫你補資料，卻不小心覆蓋掉你的隱藏公式，整張表直接「炸裂」。

分層的目的很簡單，就是為了讓我們：找得到錯、改得輕鬆、合作愉快。

三層架構

試算表的三層架構，可以用一個比喻來理解：

食材倉庫 → 廚房 → 餐盤

• 食材倉庫（原數據層）：存放原始食材，不加工、不調味
• 廚房（計算層）：把食材加工成菜餚，專注在烹飪過程
• 餐盤（呈現層）：把菜餚擺盤上桌，讓客人看起來好吃

你不會在餐盤上切菜，也不會在倉庫裡擺盤。每一層有自己的職責。

原數據層（Raw Data）

職責：只存原始資料，什麼都不做。

這一層可以有的東西：

• 手動輸入的原始資料
• 從表單收集的回應
• 從其他試算表匯入的資料
• 從外部系統匯入的 CSV 資料

這一層不能有的東西：

• 計算公式（不要在這裡做加總、判斷等運算）
• 格式化（不要在這裡上色、加粗、調字體）
• 人工修改過的資料（如果需要修正，在計算層做）

原數據層的資料就像是證據：你要保持它的原始狀態，不要加工。如果原始資料有錯，你可以在計算層處理，但不要直接去改原始資料。這樣你永遠有一個「回溯」的依據。

計算層（Calculation）

職責：所有的公式、資料轉換、邏輯判斷都在這裡。

計算層是試算表的「大腦」。它從原數據層讀取資料，用公式加工後，產出可供呈現的結果。

這一層專注的是：

• 正確性：公式邏輯是否正確？
• 可追蹤性：能不能看懂每個公式在做什麼？
• 可維護性：需求改變時，能不能快速調整？

這一層不管的是：

• 好不好看（格式化是呈現層的事）
• 排版美觀（對齊、顏色是呈現層的事）

實務上來說，這邊的計算層可以有多個工作表，像是計算層一→計算層二→計算層Ｎ的設計，只要不太影響效能，一層一層去做計算也是可以的。 另外，如果原數據層的數據要先整併過，這也是計算層可以做的事情。比如說，在原數據層，你可以有不同工作表，代表不同地方來的資料，比如「手動資料工作表」、「Google 表單回應」、「外部 API 匯入」等等，然後再利用函式把這些原數據合併起來，形成一張最終的原數據層。

呈現層（Presentation）

職責：從計算層參照結果，製作人類看得懂的報表。

呈現層不做任何複雜計算，它只是把計算層的結果「包裝」起來：

• 加上適當的格式（幣號、千分位、百分比）
• 建立圖表和視覺化
• 排版成老闆或客戶看得懂的格式
• 條件格式讓重要數字自動變色

呈現層可以有簡單的參照（從計算層讀取結果），但不應該有複雜的計算邏輯。如果你在呈現層寫了複雜的計算，那它應該搬到計算層去。

分層的效益

當你把試算表分成三層後，你會發現：

• 錯誤可定位： 報表數字不對？先查呈現層是不是參照錯了，再查計算層的公式邏輯，最後查原數據層的資料。像剝洋蔥一樣，一層一層排查。

• 變更可控制： 老闆要改報表格式？只動呈現層，計算邏輯完全不受影響。計算規則要調整？只動計算層，原始資料和報表格式都不用動。

• 協作不衝突： 你負責維護計算公式，同事負責美化報表，各做各的，不會互相干擾。

• 測試更安全： 想嘗試新的計算方式？複製一份計算層來實驗，不會影響正在使用的報表。

循環參照：分層的額外好處

分層架構還能幫你避免一個常見的噩夢——循環參照。

循環參照就是 A 依賴 B、B 又依賴 A，試算表就會陷入無限迴圈。

三層架構天然避免了這個問題，因為資料流是單向的：

原數據 → 計算 → 呈現

只要你嚴格遵守「下層不回頭參照上層」的原則，循環參照就不可能發生。

重點整理

1. 不分層的試算表 = 改不動、找不到錯、協作會打架。
2. 三層架構：原數據（食材）→ 計算（廚房）→ 呈現（餐盤）。
3. 原數據層：只存資料，不計算、不格式化。
4. 計算層：所有公式和邏輯，不管好不好看。
5. 呈現層：參照計算結果，專注報表美觀。
6. 資料流必須是單向的：這能避免循環參照。