POM 進階：Component 物件、流程串接、避免 god object

你的 HomePage 已經 200 行了，裡面有搜尋框、導覽列、推薦卡片、彈窗……每次新加功能都往同一個 class 裡塞。問題出在你把一個畫面的所有東西縫進同一個物件。 Component 物件 導覽列、底部 Tab Bar、彈窗這類 跨多個頁面重複出現 的區塊，應該抽成獨立的 Component class，再由 page 組合它，而不是讓每個 page 各自複製一份邏輯。 NavBar 繼承 BasePage，拿到 tap() 等共用操作。ProfilePage 用 local import 避開循環依賴。 HomePage 以 組合 方式持有 NavBar： ProfilePage 若也需要導覽列，同樣一行 self.nav = NavBar(driver)，不用複製任何邏輯。 多頁流程串接 每個動作回傳下一頁的物件，測試讀起來就像一條業務流程： LoginPage.login() 回傳 HomePage，NavBar.go profile() 回傳 ProfilePage，每一步型別都明確，IDE 可以補全，閱讀順序就是使用者的操作順序。測試本身不需要知道中間怎麼初始化 page。 避免 god object page 的方法一旦超過 20–30 個，通常代表它承擔了太多職責： 畫面上「設定」是一頁，但業務上是獨立的子區塊。按職責拆： SettingsPage 本身只負責「持有各子區塊」，子區塊各管各的操作，爆炸半徑縮到最小。 怎麼判斷該拆 三個信號出現一個就值得考慮： 1. 重複出現 ：同一段 locator 加操作在兩個以上的 page 裡出現 → 抽成 Component。 2. 職責太多 ：一個 page 的方法橫跨不相關的業務邏輯 → 按功能切 page 或 section。 3. 改一個地方影響太廣 ：修改某個方法要擔心 10 個測試壞掉 → 拆小，縮小影響範圍。 不要為了拆而拆。如果一個 Component 只會被一個 page 用到，直接留在該 page 的方法裡就夠了。 知道該拆，不代表現在就拆 上面講的都是「該怎麼拆」。但我自己專案裡那個又長、又纏滿平台分支的首頁物件，到現在還沒拆完。這是刻意的決定。 它確實是專案裡最貴的維護點。但我評估過，它是 美觀上的債，不是成本上的債 ：測試照樣在跑，改版時要動的地方也找得到。如果我排一段時間專門重構它，一個人做，最可能的結局是卡在中間：舊的還沒清完，新功能又進來，最後兩套寫法並存，比現在更難維護。 所以我的規則是： 不主動拆，本來就要動它的時候，順手切一塊出去。 你可能會問：上一篇的 BasePage，不就是一次集中把一個大到沒人讀得完的檔案拆成一組 mixin 的嗎？是的，而且拆得很順，靠的是比對腳本確認對外的方法簽名沒變，外面的測試完全不用改。 但 BasePage 跟首頁物件不一樣。BasePage 裡是一個個獨立的共用動作，點擊歸點擊、滑動歸滑動，切線很清楚。首頁物件裡是一條條業務流程，還纏著一堆平台分支，切下去哪裡會斷，很難事先看清楚。集中拆一個切線清楚的檔案是可行的；集中拆一個切線不清楚的檔案，就是我前面說的，容易卡在中間。 抽象層不要多過維護的人 Component、section、流程物件，每一種都是一層抽象。層數多，每一層的程式都變短了，但要理解一個動作到底做了什麼，得一層一層追下去。 我給自己定的上限是： 抽象層的數量，不要超過維護這套框架的人數 。我們只有我一個人，所以能少一層就少一層。層數超過維護人數，專案裡就會出現「沒人敢改」的區域，因為沒有人記得全部的層是怎麼接起來的。 這也是為什麼上面「怎麼判斷該拆」的最後一條那麼重要：只有一個地方用到的 Component，就不要抽。 一個更大的例子：適配，還是重寫？ 同樣的判斷，我在一個更大的決策上也用過。當時要評估框架要不要支援一個新的行動作業系統，選項有兩個： | | 在現有框架加適配層 | 重寫一套新框架 | | | | | | 時間（一個人） | 幾週 | 半年以上 | | 風險 | 低，可以隨時拿掉 | 高，做到一半很難回頭 | | 維護負擔 | 一套程式碼 | 兩套並存 | 評估的結論是適配。重寫最致命的，是那段期間要同時維護兩套框架：舊的出問題只有我能修，新的出問題也只有我能修。適配的規劃跟拆 god object 是同一個思路：不改現有的程式碼，在旁邊加一層；平台差異寫在設定檔；分階段做，每個階段結束都要能跑，隨時可以停。 結果最後連適配都沒做。算下來，就算是便宜的那個選項，對一個人來說成本還是太大，當時手上還有更該做的事。 我不覺得那份評估白做了。它讓「要不要支援」從一個模糊的焦慮，變成一個有數字、可以拍板的決定。有時候評估完的最好結論，就是先不做。 對一個人維護的框架來說，「能不能在做到一半時停下來」比「架構漂不漂亮」更重要。