元件設計權衡上帝物件博弈與 SRP 原則 從九把刀與瑞士刀看 React 元件開發單一職責

什麼是元件設計中的「九把刀」與「瑞士刀」模式？

在軟體元件設計中，開發者常面臨拆分與整合的權衡。「九把刀」模式 傾向於將功能極端細分，確保每個元件極度專一，但缺點是當相似需求變動時會引發 散彈槍式修改 (Shotgun Surgery) —— 需要在數個小元件中同步調整相同邏輯。反之，「瑞士刀」模式 將多種功能封裝於單一元件，雖方便重用，卻容易導致元件過度膨脹，演變成難以維護的 上帝物件 (God Object) 並引發 發散式修改 (Divergent Change)。理想的架構應落實 單一職責原則 (SRP)，在元件的「專一性」與「通用性」之間找到平衡點，確保系統具備高品質的擴展性。

大家不知道有沒有過一種經驗，新買的東西包裝都沒拆結果一直放著，堆在箱子或是櫃子中一放就是好幾年。在軟體開發中，這就像沒有經過良好管理的程式碼，留下了許多沒用到但大家也不敢刪除的邏輯，最終導致系統臃腫。

整理東西應該是依照物品來做分類和整理，而非依照場所。

這是在上一篇文章的結論，那在實際上會是什麼意思?

小編在另外一篇文章前任物品斷捨離 X 專案資料夾架構與收納，有簡單快速的提到專案資料夾架構怎麼依照屬性或是功能分類，依照檔案的多寡和專案的大小各自會有各自的好處，但實際上都會以物品本質為出發點，像是按照衣服、褲子、內搭、外套去做屬性分類，但量一多就會變成很難找到整套運動服。

元件管理：專一性與通用性的博弈

回顧一下專案假設今天總共用五個階段五個角色，每個角色在不同階段需要填的欄位並不相同，可以想像一個班級有不同的幹部，而班級學期報告需要大家按照各自的職掌在不同階段逐漸把內容完善。

在軟體工程中，元件的設計往往面臨兩種選擇。我們在進行 程式碼重構 時，必須在「專注拆分」與「高度整合」之間做出決定：

1. 九把刀模式 (拆分元件):
   一開始我們被要求做出五個角色要用的刀子，隨著需求演化成美工刀、水果刀、菜刀。這種做法讓每個元件都很純粹，但當需要改動相似功能時，就會面臨一次要改很多地方的命運，這就是 散彈槍式修改 (Shotgun Surgery)。

2. 瑞士刀模式 (合併元件):
   將相同類型的物件集中，演化成集多功能於一身的瑞士刀。這會導致 發散式修改 (Divergent Change)，因為你會在一個元件上長出各種奇形怪狀的功能，最終演變成上帝等級的 上帝物件 (God Object)。

權衡之道：如何運用單一職責原則 (SRP)？

在 軟體架構設計 中，我們該如何決定要選「九把刀」還是「瑞士刀」？這時 單一職責原則 (Single Responsibility Principle, SRP) 就能派上用場。一個良好的元件應該「只有一個引起它變化的原因」。

• 如果一個元件同時負責處理資料請求、渲染複雜 UI 以及管理多個角色的權限，那它就是一個危險的 上帝物件。
• 如果為了極端解耦，連一個簡單的 Button 都拆分成五個不同樣式的獨立元件，那未來修改按鈕色調時就會引發 散彈槍式修改。

正確的策略是：將「易變的業務邏輯」與「穩定的 UI 呈現」分離，並在元件過於龐大時及時重構，確保每個元件都擁有清晰的邊界。

Kanban：任務管理中的斷捨離

在專案管理上，Kanban 的概念也是依照任務的本質去做分類，將相關任務集中在一起。這與 元件設計模式 異曲同工，旨在清晰地呈現狀態流轉：

• 待處理 (To-Do): 尚未開始的功能或收納任務。
• 進行中 (In Progress): 正在開發或整理的邏輯。
• 已完成 (Done): 已經重構完成並通過測試的項目。

所以今天如果給你選，你會選擇九把刀還是瑞士刀呢？其實選擇並沒有絕對的好壞，這取決於當下的時程、團隊組成以及專案的複雜度。掌握 上帝物件 與 散彈槍式修改 的特性，能幫助我們在開發過程中做出更明智的架構選擇，讓每一天都能早點下班。

FAQ：元件設計常見問題

Q1：我的元件現在長得很大，怎麼判斷它是否變成了上帝物件？

A：觀察它的「Props」和「useEffect」。如果一個元件有超過 10 個以上的 Props，或者 useEffect 中包含了大量互不相干的邏輯，那它就是上帝物件的候選者。另一個徵兆是：每當您想修改一個小功能，卻發現必須小心翼翼不破壞其他五個不相關的功能時。

Q2：如何優雅地解決散彈槍式修改 (Shotgun Surgery)？

A：解決之道在於「提取共用邏輯」。您可以將重複出現的程式碼提取為 Custom Hook 或者一個 基礎元件 (Base Component)。這樣，當共通邏輯變動時，您只需要修改該 Hook 或基礎元件一處，而不需要「開著散彈槍」到處補洞。

Q3：所有的元件都必須嚴格遵守 SRP 嗎？

A：過度設計也是一種病。 在開發初期，為了速度可以適度容忍一些「多功能元件」。但關鍵在於具備「重構的意識」：一旦該元件的修改頻率變高，或者邏輯複雜度讓新同事難以理解，就必須無情地進行斷捨離，將其拆分為多個職責單一的小元件。

• ← 上一篇
• 下一篇 →