Platform team 經驗分享 - Design Review

過去我曾在 ShopBack 的 Mobile Platform Team 工作，對一名 iOS 工程師而言，這是一段非常不同的經驗。因此，我想把一些值得分享的工作內容整理出來，尤其聚焦在這次要談的 Design Review。

什麼是 Mobile Platform Team？

簡單來說，Mobile Platform Team 的核心目標是「支持和增強 feature team 的生產力」，並且通常透過構建工具、框架與基礎設施的方式來實現。

以下是常見的主要任務：

• 基礎架構設計與優化

  • ex: 重構、模組化，降低耦合性

• Shared Frameworks 與 Tools 的開發

  • ex: Shared UI Components, API, EventTracking, Debug System, Feature Flags

• CI/CD 流程與自動化

  • ex: MR 自動觸發 Unit/UI Tests、自動打包與發版、整合測試結果與發版訊息至 Slack。

• 性能與穩定性監控

  • ex: 監控啟動時間、API 請求頻率、整理與解決 Crash 報告。

• 設立技術標準與最佳實踐( Best Practices)

  • ex: 制定 Coding Guideline、為 Frameworks/Tools 撰寫文件與使用說明。

• 跨團隊支持與協作

  • ex: 在功能 Migration、整體性實作 (如 Rebranding) 介入協助。

• 無法識別的緊急任務處理

  • 所有不知道是誰的鍋，先給 Platform Team 再說 🤣

  • ex: 功能異常但找不到 Owner 時，先由 Platform Team 進行問題釐清或處理。

雖然 Platform Team 有很多領域可以深入探討，但這次要分享的重點主要放在 Design Review。

為什麼需要 Design Review？

對 Platform Team 而言，常會開發 Shared Frameworks 或是共用的 UI Components，其對象不是最終使用者 (Customers)，而是其他開發者 (Developers)。

• 這代表：

  • 我們提供的工具或框架，必須能整合、支援所有開發者的需求。

  • 一旦被廣泛使用後，任何設計變更都會帶來較大的影響，包含相依性 (Dependency) 與向下相容等問題。

  • 在正式實作前，需要確認該設計是否會造成額外耦合、或是日後難以維護與擴充。

  • 實作後也需要有明確的文件、範例，以供其他開發者正確使用或進行 Migration。

這便是進行 Design Review 的原因：在 Implementation 前先檢驗架構、考量未來擴充性，並在完成後能快速且正確地被其他開發者採用。

Design Review 流程與範例

以下將以一個簡單的 Shared UI Component（假設我們要做一個客製化的 Toast/Banner 來顯示重要訊息）作為範例，說明整個 Design Review 的四大步驟。

Step 1: 可能影響範圍研究 (Impact Analysis)

• 1.1 目的

  • 了解即將開發的功能或元件，在哪些模組或流程中會被使用或替換。

  • 預先評估風險，像是哪些現有功能會依賴同樣的元件、或需要配合調整。

• 1.2 範例情境

  假設目前有多個 Feature Teams 都需要顯示提示訊息，使用的方式各不相同：有人使用第三方函式庫，有人自己寫了一個 Alert，還有人整合在自訂的視圖裡。

  Platform Team 打算做一個統一的 Shared Toast Component，讓各 Feature Team 都能透過相同介面呼叫。

研究要點：

• 列出所有可能用到 Toast/Banner 的功能。

• 比對第三方函式庫與既有 Alert 的使用方式，確認切換到新元件時，會不會破壞既有流程或 UI 風格。

• 確認是否需要額外的設定或初始化。

• 1.3 小提示

  • 可以在文件上，將研究結果記錄下來，包含「目前使用情況」、「已知相依關係」，便於 Review 時所有人了解前因後果。

Step 2: 預計實作的 Class Diagram (UML/類別圖)

• 2.1 目的

  • 在實際撰寫程式前，把主要的類別、類別屬性、Protocol、相依關係畫出來。

  • 讓大家可以從整體設計的角度，檢視未來維護與擴充的可行性。

• 2.2 範例設計

  以下為一個簡化的類別圖 (UML) 範例，可透過任何 UML 工具繪製。(私心推薦 PlantUML)

Class Diagram

• ToastManager：負責對外提供顯示 Toast 的介面，統一管理 Toast 狀態 (是否已顯示、排隊等)。

• ToastView：負責顯示實際的視圖 (UI)，會根據 ToastConfig 設定樣式、動畫等。

• ToastConfig：定義樣式與行為，如顯示的文字、顯示時間、樣式 (背景顏色、文字顏色…)。

Step 3: Best Practices

• 3.1 目的

  • 為後續使用、擴充、維護訂下指引，避免日後發生程式風格或設計上不一致的問題。

  • 提供與整體專案規範一致的建議 (如命名規則、UIKit vs SwiftUI、相依注入方式、日後 Migration 計劃等)。

• 3.2 Best Practices

  • 給予開發者指示"該做什麼"，才能呈現對應的項目，像是

    • 要 Import 哪個 framework

    • DI 的方式是什麼

    • 要建立什麼物件，物件的屬性分別對應到的功能是什麼

  • 範例

// 如果要使用 ToastManager 則要先 import 
import SharedUI

class FeatureAViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        
        // 例如在某個情境下顯示 Toast
        showSuccessToast()
    }

	private func showSuccessToast() {
        // 建立 ToastConfig 設定 Toast 的屬性
        let config = ToastConfig(
            message: "Data saved successfully!",
            duration: 2.0,
            style: .success
        )
		// 使用 Singleton ToastManager
		// 注入 config，用以呼叫 Toast
        ToastManager.shared.showToast(config: config)
    }
}

Step 4: Review by Developers and Adjustment

• 4.1 目的

  • 與其他相關開發者進行檢討，確認實作方式是否可行，是否符合各團隊需求。

  • 收集回饋，若有潛在問題或改善空間，盡早進行調整，以免後期大規模重構。

• 4.2 收集意見

  • Feature Teams 是否有特殊需求？例如 Toast 是否需要在背景音樂播放時靜音、或自動排隊顯示等？

• 4.3 調整

  • 彙整回饋後，更新設計文件、進行修改。

結論

Design Review 在 Platform Team 的工作流程中扮演關鍵角色。

• 在實作前 先經過研究、架構設計 (Class Diagram/UML) 與可能影響範圍的評估，可以有效降低日後重複改動的成本。

• 在實作後 透過文件與 Review，把最佳實踐與後續維護方式明確化，讓 Feature Teams 能順利接手與使用。

這樣的流程不僅能提升整體開發效率，也能讓 Platform Team 更快聚焦在「如何提供更好的工具、架構與最佳實踐」，從而增強整體產品的生命力。如果你或你的團隊也在處理類似的 Platform 任務，不妨試著導入或優化 Design Review 的流程，讓開發更有效率、更可預期。