25#8 分享年度考核規劃以及程式設計架構高內聚與低耦合怎麼設計

ChinSheng

Apr 21, 2025

管理分享

這期想跟大家分享跟成員做年度考核 (Annual Appraisal) 時，應該要怎麼規劃與進行。

這是以年底進行 Appraisal 來規劃的時間建議。

🔹 Q1（1～3 月）：目標設定

和每位成員進行年度目標 1 on 1
對齊公司 / 團隊目標（如 OKR）
根據職級 / 職能制定個人成長計畫（IDP）
檢視上一輪 appraisal 的改善項目

🔹 Q2（4～6 月）：回顧與調整

和每位成員進行年中的 1 on 1 回顧
跟成員確認目標達成進度與遇到挑戰
必要時調整目標或支援策略
強化回饋機制與團隊技術交流

🔹 Q3（7～9 月）：成果累積與整理

提供跨專案機會或領導角色，累積成果
聚焦技術深耕或職能補強（根據 IDP）
引導成員準備年終成果資料

🔹 Q4（10～12 月）：年度評估與未來規劃

啟動年終 Appraisal 流程（Self-review、Peer-review、Manager review）
撰寫並提交主管評語（根據全年紀錄）
與成員進行年度評估面談（包含調薪/升遷建議）
與成員共同檢討全年表現，啟動下年度方向討論

其實整體流程的核心在於為每位成員制定 IDP（Individual Development Plan，個人發展計劃），這個計劃需對齊公司與團隊的整體目標，並根據每位成員所屬的職級，設定具體可衡量的發展方向。

在 Q2 與 Q3 的階段，我們會逐步追蹤並蒐集成員在 IDP 上的執行成果與達標狀況。這些紀錄需具體明確，能說清楚成員在某個專案中參與的角色、完成的工作內容，以及有哪些具體貢獻與改進空間。

到了 Q4 進行年度 Appraisal 時，這些資料將作為主要依據，協助評估整體表現。若成員在 IDP 的執行成果明顯偏低，且缺乏具體改善行動，就有可能進一步進入 PIP（Performance Improvement Plan，績效改善計畫）階段。

技術分享

這期想跟大家分享高內聚 (High Cohesion) 與低耦合 (Loose Coupling) 的概念

🔹高內聚

定義：一個模組（或類別）裡的功能彼此高度相關、有一致性。
目標：讓每個模組專注做一件事，功能明確。
優點：易於理解、測試和維護。

🔹低耦合

定義：模組彼此之間依賴程度低，不會直接控制對方的行為。
目標：讓一個模組變更時，其他模組不用或很少跟著改變。
優點：彈性高，可替換性強，容易單元測試。

我們會希望程式架構朝著高內聚與低耦合的架構前進，但實際上在實作過程中，則是會出現三個版本。

高內聚，高耦合
低內聚，低耦合
高內聚，低耦合

現在我們用使用者註冊功能這個需求，用 Go 實作三個版本的範例，來幫助大家理解，這三個版本，應該會長成什麼樣子。

🔹版本一、高內聚，高耦合

type UserService struct{}

func (s *UserService) Register(email, password string) error {
    // 驗證 email
    if !strings.Contains(email, "@") {
        return errors.New("invalid email")
    }

    // 模擬儲存
    fmt.Println("Saved:", email)

    // 模擬寄送歡迎信
    fmt.Println("Sent welcome email to:", email)

    return nil
}

func main() {
    service := &UserService{}
    err := service.Register("test@example.com", "123456")
    if err != nil {
        fmt.Println("Register failed:", err)
    } else {
        fmt.Println("Register success!")
    }
}

這個版本應該是每個軟體工程師剛開始接觸程式時會寫的版本，或是 PoC 版本為了實現功能的可行性。

優點

業務流程集中在 UserService，邏輯一目了然（高內聚）
初期開發快速直觀，容易看懂
不需要額外抽象、interface，程式碼少

缺點

直接綁定底層技術（DB、SMTP），導致耦合高
單元測試會比較複雜
變更其中某一個流程（如改寄信服務）時要改核心邏輯
無法重用或替換元件

🔹版本二、低內聚，低耦合

type Validator struct{}
func (v *Validator) Validate(email string) error {
    if !strings.Contains(email, "@") {
        return errors.New("invalid email")
    }
    return nil
}

type DBWriter struct{}
func (d *DBWriter) Save(email, password string) error {
    // 模擬儲存
    fmt.Println("Saved:", email)
    return nil
}

type EmailNotifier struct{}
func (n *EmailNotifier) Send(email string) error {
    // 模擬寄送歡迎信
    fmt.Println("Sent welcome email to:", email)
    return nil
}

// 外部流程直接串接各個元件
func RegisterUserFlow(email, password string) error {
    validator := &Validator{}
    dbWriter := &DBWriter{}
    notifier := &EmailNotifier{}

    if err := validator.Validate(email); err != nil {
        return err
    }
    if err := dbWriter.Save(email, password); err != nil {
        return err
    }
    return notifier.Send(email)
}

func main() {
    err := RegisterUserFlow("test@example.com", "123456")
    if err != nil {
        fmt.Println("Register failed:", err)
    } else {
        fmt.Println("Register success!")
    }
}

這個版本比上一個版本更進階，我們試圖想要減少功能的耦合性，但卻可能造成業務邏輯的分散。

優點

各模組單一責任，容易替換與測試（低耦合）
無硬綁定底層邏輯，可抽換不同實作（如 mock / stub）
方便獨立維護與重複使用元件

缺點

業務流程邏輯分散在 main() 或 controller（低內聚）
沒有中心協調者，不利於維護流程變化
每次要新增流程（如 log、驗證碼）都要改外部流程呼叫
難以重用整體註冊邏輯

🔹版本三、高內聚，低耦合

type EmailSender interface {
    Send(email string) error
}

type UserRepo interface {
    Save(email, password string) error
}

type Validator interface {
    Validate(email string) error
}

// EmailSender 實作
type SimulateEmailSender struct{}
func (s *SimulateEmailSender) Send(email string) error {
    fmt.Println("Send welcome email to:", email)
    return nil
}

// UserRepo 實作
type SimulateUserRepo struct{}
func (r *SimulateUserRepo) Save(email, password string) error {
    fmt.Println("Saved user to DB:", email)
    return nil
}

// Validator 實作
type SimpleValidator struct{}
func (v *SimpleValidator) Validate(email string) error {
    if !strings.Contains(email, "@") {
        return errors.New("invalid email format")
    }
    return nil
}

type UserService struct {
    validator Validator
    repo      UserRepo
    sender    EmailSender
}

func (s *UserService) Register(email, password string) error {
    if err := s.validator.Validate(email); err != nil {
        return err
    }
    if err := s.repo.Save(email, password); err != nil {
        return err
    }
    return s.sender.Send(email)
}

func main() {
    service := &UserService{
        validator: &SimpleValidator{},
        repo:      &SimulateUserRepo{},
        sender:    &SimulateEmailSender{},
    }

    err := service.Register("test@example.com", "123456")
    if err != nil {
        fmt.Println("Register failed:", err)
    } else {
        fmt.Println("Register success!")
    }
}

這個版本通常已經是維護到中大型專案時，很常見的程式架構。

優點

業務邏輯集中在 UserService（高內聚）
所有依賴透過 interface 傳入，方便替換 / 測試（低耦合）
新增流程只需修改 UserService，維護成本低
測試時可 mock interface，單元測試容易寫
更符合 Clean Architecture、SOLID 原則

缺點

初期設定較多，需要定義多個 interface 和實作
對小型專案來說略顯複雜（但對中大型專案是必要的）

結論

在團隊管理上，透過明確規劃 IDP 與 Appraisal 節奏，可以幫助成員有方向地成長，讓績效回饋更具建設性；而在系統設計上，實踐高內聚與低耦合的原則，則是打造可維護、可擴充架構的基石。無論是管理人還是工程師，持續優化這兩個面向，才能讓團隊穩健前行。

ChinSheng’s 探索紀錄

Discussion about this post

Ready for more?