本卡的論述基於八方雲集案例分析的結構拆分。初版文章同時承擔兩個分析責任：八方自身的商業模式與財報判讀，以及八方與揚秦的跨公司結構比較（八維比較表 + 獲利結構比較表 + 散落在各段的比較句）。拆分後三個效果立即可觀察。限制：觀察來自單一次拆分，但原則適用於所有「個體分析 + 跨個體比較」並存的文章結構。

核心原則

個體的深度分析和跨個體的結構比較是兩個獨立的分析責任——各自有不同的讀者需求、不同的擴充方向、不同的資料組織方式。 把兩者塞在同一篇文章裡，兩邊都做不深：案例分析的篇幅被比較內容佔用，比較內容被鎖在單一公司的敘事脈絡裡無法獨立擴充。

拆分後的三個效果：

1. 案例文章深化。八方文章移除比較段後，騰出空間深化營業槓桿的雙面性（正向放大 5.2 倍 + 反向風險）、德州工廠 300 產能 vs 13 間店的閒置壓力、同店來客數 vs 營收成長率的判讀差異、丹堤和芳珍蔬食的定位問題——這些分析在原版被比較表格擠掉了。
2. 比較文章可擴充。比較篇獨立後，之後加入三商餐飲（7705）或其他加盟母公司只需要在既有比較軸加行，不需要改動任何一篇案例文章。
3. 被引用的文章也深化。揚秦文章原本用兩段解釋八方的模式來說明毛利率差距；拆分後改為引用比較篇，騰出空間深化揚秦自身的關係人交易判讀方法（年報附註查超秦採購比例 → 比對超秦毛利率 → 判斷改善來源）和展店落差的三面向分析。

反模式：在案例文章裡內嵌完整比較

案例文章裡出現「跟 X 的比較」段落有兩種情境：

比較服務案例的論點——用一句「同業 X 的毛利率 36%，差距 9pp」建立參考基準，讓讀者理解本案例的相對位置。這種引用是案例分析的一部分，佔一兩句，不需要拆分。

比較本身是獨立的分析——用完整的多維比較表、逐維度拆解差距原因、得出結構性結論。這已經不是「引用基準」而是「做比較分析」，承擔的是跨公司比較的分析責任。這種段落嵌在案例文章裡會造成兩個問題：案例文章的讀者被迫讀完比較才能繼續、比較內容的讀者要先進入一家公司的脈絡才能找到比較表。

判別方式：刪掉比較段落後，案例文章的分析是否仍完整。如果完整，比較段應該獨立成篇。

跟其他原則的關係

判讀徵兆

觸發場景：Flutter 書籍管理 App 的兩份重構評估、相隔一個版本：_executeImport() 88 行被拆成 13 個項目、主函式剩 17 行；executeBatchImport() 約 90 行、評估結論是不拆。同一個團隊、同一條「函式 5-10 行」規範 疑問來源：兩個幾乎同規模的函式、兩個相反的處置、而且讀完兩份記錄會同意兩個都對——那「5-10 行原則」到底在判什麼？ 整理目的：把「拆 / 不拆」的實際判準從行數規則裡拆出來、記下兩個 case 各自的診斷依據 本文邊界：素材是該專案 v0.26 的拆分記錄（含事後逐函式評估）與 v0.25.1 的保留評估；「5-10 行」是該專案的 house rule、判準本身不綁定這個數字

拆的 case：五種職責、五層巢狀

_executeImport() 的 88 行不是「一件事寫得長」、是五件事擠在一起：狀態初始化、主迴圈、重複檢測（skip / overwrite / merge / cancel 四種策略的 switch）、儲存、結果統計。巢狀深度五層——for 迴圈裡有 try-catch、裡面有 if、再裡面 switch-case。讀它的人要同時持有五個心智堆疊。

拆完的形狀：主函式 17 行、變成讀得像流程描述的協調者（initialize → process → finalize）；12 個子函式全部動詞開頭、各答一個「它在做什麼」（_handleExistingBook、_saveNewBook、_recordBookError……）；最深巢狀從 5 層降到 2 層。

兩個工法值得單獨記。_ImportProgress 輔助類別：拆函式最常見的副作用是子函式之間要傳一長串計數器參數，這裡把進度狀態（成功數、失敗數、處理索引）收進一個 6 行的私有類別、參數列縮成一個物件——拆函式前先看有沒有該收斂的「隱形狀態群」。測試零改動：209 個測試全過、一個都不用改，因為測試斷言的是匯入行為（結果、事件、狀態）而不是內部結構——這也是反向的檢驗：重構會逼你改測試、通常代表測試耦合了結構。

事後評估同樣誠實：13 個項目裡 7 個完全符合五行原則、4 個在 10-15 行（協調函式與 switch 結構、判可接受）、1 個 20 行標「需關注」。拆完也不是教條達標——原則是方向、不是驗收線。

不拆的 case：步驟多、但答案只有一個

executeBatchImport() 約 90 行、同樣超標，評估卻判「不拆、優先級低」。理由寫在記錄裡：

executeBatchImport 雖超過 10 行，但為完整業務流程；已適當拆分子函式（_updateProgress、_rollbackImportedBooks）；強制拆分可能降低可讀性，不符合「可讀性優於簡潔性」原則。

看它的結構就懂了：狀態初始化、發布開始事件、然後是一個 40 行的主迴圈——每一輪做取消檢查、暫停等待、處理一本書。它的長度來自流程的步驟數、不是職責的混雜：問「這個函式在做什麼」只有一個答案（執行可中斷的批量匯入）、而且這些步驟的順序與交織正是這個功能的本體——取消檢查必須在每輪迴圈裡、暫停等待必須在處理之前。強拆的結果是把「一眼看完整條流程」變成在五個函式之間跳讀、每跳一次丟一次上下文。

值得補的是它已經拆過該拆的：進度更新跟回滾各自成函式。保留的是流程骨幹、不是偷懶的整坨。

判準：先診斷成因、再決定處置

兩個 case 並排、判準自己浮出來。函式長是症狀，處置取決於成因：

輔助判讀有兩個：巢狀深度比行數誠實（5 層巢狀幾乎必然是職責混雜；90 行但迴圈內平鋪、常是流程）；試拆測試——想像拆出來的子函式，它有獨立的名字跟意義（_saveNewBook）就該拆，它只能叫 _executeBatchImportPart2 就不該拆。

行數規則的正確角色是觸發器、不是判決：超標的函式值得被看一眼，看的結論可以是拆、也可以是「完整流程、保留、記錄理由」。這個專案把保留理由寫進評估記錄——下一個看到 90 行函式的人讀得到「為什麼它被允許長」，而不是以為前人漏了。

判讀徵兆

• 函式超長且巢狀超過三層——職責混雜的高機率訊號、優先拆
• 拆分後子函式之間要傳一長串狀態參數——先收斂成輔助類別、再拆
• 重構函式結構逼得測試要跟著改——測試耦合了結構、先修測試的斷言對象
• 「不拆」的決定沒有留下理由——下一輪 review 會重新爭論一次；把「完整業務流程、強拆降可讀性」寫進記錄

相關閱讀

• 同專案的可讀性家族：typedef 改寫前後比較——那篇是型別層的可讀性手法、本文是結構層
• 「規則是觸發器不是判決」的原則層：#149 keyword bank 命中是候選、不是判決——寫作 lint 與函式長度規則同構：偵測可機械化、判定要看語意
• 測試守護重構的前提：192 個測試全過、實機全壞——測試耦合行為才有守護力，本文的 209 個零改動測試是正面樣本