"Srp"
- Single Responsibility Principle（單一職責原則）
要判斷一個模組、類別或文件該不該拆，或讀到「一個類別只做一件事」這種說法時：單一職責的定義是改變的理由，理由以改動的種類計數，提出變更的人用來辨認種類
- 從修改紀錄畫模組邊界：修改競爭、熱點的量測與分類、職責歸類、拆分時維持行為的做法、拆分時機與拆完的驗證
用 git 歷史統計每個檔案被幾個不同的需求修改、把結果當成單一職責的間接量測，修改熱點的分類與處理，逐個 commit 把需求歸到職責以決定切法，拆分時與語言無關的做法（特徵測試、搬移與修改分開提交、單向依賴），以及拆分合併的時機與拆完之後的驗證；量測只讀版本歷史，與程式語言無關
- 拆分 Python 模組：pytest 的特徵測試、同名套件與重新匯出、自動登記的分派表、避免循環匯入
職責邊界已經從修改紀錄歸類出來之後，用 Python 拆分一個模組而不改變對外行為：用 pytest 寫特徵測試與 monkeypatch 的替換目標、改成同名套件並重新匯出、把巨型分支改成自動登記的分派表，以及拆出模組之間循環匯入在 Python 的症狀與解法
- 案例文章跟跨公司比較是兩個分析責任
案例分析文章裡嵌了跨公司結構比較時，兩個責任互相擠壓——案例深度被比較段佔空間、比較段被鎖在單一公司的脈絡裡無法擴充；拆成各自獨立的文章後兩邊都能深化
- 文件的職責數從修改紀錄讀出：長度當拆分訊號的誤判、加段落之前的檢查與拆完之後的外部引用
要往既有的文件或規則檔加一節、懷疑一份文件塞了多種職責、或剛拆完一份文件要處理原檔與指向它的引用時，用來判斷是否拆分、沿哪條軸拆與拆完要補什麼
- 依職責拆分文字文件：修改紀錄的訊號、切法與拆完之後的引用
規則文件、操作手冊與範本的拆分：從版本歷史讀出一份文件承擔幾種職責，依職責而非長度決定切法，原檔保留導覽表、同一條規則只定義一次，以及拆完之後更新引用與檢查新檔之間的指引缺口
- 88 行拆成 13 個函式、90 行決定不拆 — 函式長度是症狀、職責才是診斷
同一個團隊、同一條 5-10 行規範、兩個 90 行上下的函式，一個拆一個保留、兩個決定都對。判斷標準在行數之外：職責混雜（初始化/迴圈/儲存/統計擠一起、巢狀五層）拆之，完整業務流程（步驟多但答案只有一個）留之。含 _ImportProgress 收斂參數列與測試耦合行為的守護。