前言

當我實作畫面流程時，我會為一組「流程」建立一個 Coordinator。如果這組流程很複雜，它可以拆分成多個「子流程」，那每一個子流程也會有對應的 Sub-Coordinator。主流程的 Coordinator 可以管理子流程的 Sub-Coordinator。

Coordinator 用來管理流程的畫面，它負責建立畫面、傳遞資料給畫面、回應畫面的請求、移除畫面等等。如果用 tree 來理解畫面流程的話，Coordinator 就是 root，各個畫面就是 leaf。換個角度看，Coordinator 像一個容器 — 它自己不產出畫面內容，而是決定裡面放哪些畫面、什麼時候切換。

Xcode 的 project.pbxproj 檔案採用文字格式儲存專案結構，但 Xcode 在新增檔案或修改設定時，不保證項目的插入順序一致。多人協作時，即使修改不同的檔案或 target，也可能因為項目順序差異而產生 merge conflict。這些衝突往往與實際變更無關，純粹是格式問題。

我的解決方案

將 project.pbxproj 中的各個區塊按固定規則排序，確保相同內容產生相同的檔案結構。配合 git pre-commit hook，每次提交前自動排序，團隊成員的專案檔就能維持一致的順序，大幅降低無意義的衝突。

我開發了一個腳本工具來執行這個任務，也已經在多個專案上跑了好幾年，GitHub repo 放在這裡：https://github.com/chiahsien/sort-Xcode-project-file

雖然目前推崇使用 Swift Package Manager 進行模組化，Xcode 16 也引入了 buildable folders 功能來減少專案檔變更，甚至也有 Tuist 或 Xcode Gen 這類的工具來生成專案檔，但這些新技術主要針對新專案或願意大幅重構的專案。對於已經開發多年、結構複雜的舊專案，貿然改用 SPM 模組化或轉換成 folder references 風險過高。此時，這個排序工具仍是最務實的選擇，能以最小成本解決 merge conflict 問題。

這次要介紹的是我為 KOReader 檔案瀏覽（Mosaic）所做的另一個 userpatch：2-browser-folder-cover.lua。這個 patch 可以讓資料夾在 Mosaic 檢視時顯示封面圖片，支援放置自訂 .cover 檔案，若無自訂封面則會自動從該資料夾或其子資料夾的書籍取得封面。此外還提供兩種顯示風格：單一封面或 2×2 格狀封面。

下載路徑：https://github.com/chiahsien/KOReader.Patches

在專案開發到一定規模後，你可能會發現某些 feature 其實相對獨立：它們有自己的流程、畫面、資源檔，甚至可以被其他專案重用。這時候，最乾淨、最有彈性的做法，就是把它抽成 Swift Package。

以我最近在做的功能為例，它是一個完整的獨立模組 - 有多個頁面、支援多國語言、使用圖片與動畫資源。為了避免日後整合時出現命名衝突、相依過重或編譯過慢的問題，我選擇把它獨立成一個 Swift Package。在將 feature 抽出到 Package 的過程我也踩到了一些坑，趁著這個機會記錄下來，以免日後忘記。

為什麼要把 Feature 打包成 Swift Package？

建立專屬的 Swift Package 有幾個明顯的好處：

• ✅ 可獨立開發與測試：模組化後不必依賴主專案，可單獨編譯與驗證。
• ⚙️ 降低相依與衝突：減少命名重複、依賴鏈過長等問題。
• 🚀 加快編譯速度：主專案不需每次都重新編譯整個功能。
• 🔄 方便整合與重用：未來可以直接被其他 app 或團隊使用。

工程師都會有自己習慣的電腦設定，我自然也不例外。本文記錄了我自己的環境建置，方便以後換電腦或換工作時可以快速 setup。

我用的瀏覽器主要是 Chromium based，從早期愛用的 Google Chrome，到現在改用 Vivaldi、Brave Browser、Arc、Dia。有時還會用 WebKit based 而且支援 Chrome/Firefox 套件的 Orion Browser。

每次換工作都是一次整理工作環境的機會，我的瀏覽器也藉此重裝，雖然每次的工作都不完全一樣，但我發現有些 extension 是不管在之前還是現在的工作、不管是公司還是家裏都會安裝的。以下就是我必備的幾個 extension：