寫出好維護的程式碼 — 低耦合

在這個單元我們要來談耦合，以及如何透過這個原則，讓我們在寫程式的時候，能夠讓程式碼更容易修改跟拓展。

相信多數人可能過去都聽過高內聚、低耦合這兩個概念放在一起談。我們在上一個單元談了高內聚，在這個單元我們會進一步談低耦合，讓大家知道這兩個概念放在一起，可以如何一起讓我們的程式碼變得更容易維護。

複雜度與可維護性

在這邊我們再複習一下前面的單元。要讓程式碼能夠好維護，就是讓程式碼的複雜度要低，推薦有兩個檢視指標：

第一個是程式碼是不是好讀的，也就是過去假設沒有碰過這段程式碼的人，他第一次看到這段程式碼，能不能用非常短的時間就去理解這段程式碼。
第二個指標是好改，也就是如果某一個未來想要去維護這段程式碼的人，想要去做改動，會不會想改的時候發現很難改，還是可以相對來講很簡單地去做他想要做的改動。

從耦合的角度來看，在好讀的部分可能幫助並沒有到那麼大，但是假設從好改的角度來看，讓程式碼的耦合性降低，是能夠讓程式碼的好改程度變高非常多。所以從複雜度的角度來看，低耦合這件事情也是非常有幫助的。

什麼是耦合?

首先我們先來理解一下耦合這個詞代表什麼樣的概念。所謂的耦合就是指事情相互牽扯的程度，也就是兩個東西，它們彼此有沒有互相的依賴、彼此糾纏在一起。假設有的話就是耦合度高，但假設彼此沒有這種相互的牽扯、糾纏、依賴的話，那就是耦合度低。

事實上我們在日常的生活當中，也會看到不同的耦合的狀況，不只是在程式當中而已。

舉一個生活常見的案例，在過去蘋果推出新手機的時候，使用的充電線都是蘋果自家的 Lightning 充電線。用 Lightning 充電線的問題就會是，假設今天某一個用 iPhone Lightning 充電接頭手機的人，出門手機要沒電了，發現自己忘了帶充電線，去跟身旁的人借，結果身旁的人都是使用 Android 的手機，都是使用標準的 Type-C 對 Type-C 的接頭。

在這個狀況下，因為蘋果的手機跟 Lightning 的充電線是彼此耦合的，所以就變成它要充電的話，沒有辦法使用 Type-C 充電線。所以在這個時候，假設忘了帶充電線，但身旁的人又都是用 Type-C 的充電線，就會導致想要借，借到了也沒有辦法充。

但反之，假設某一個人是用 Android 的手機，他出去忘了帶充電線，旁邊的人也都是使用這種標準化 Type-C 對 Type-C 接頭的充電線，那這樣子他忘了帶充電線也沒有關係。因為他的充電的接頭，並沒有跟某一個特定的充電接口是耦合的，所以他就可以非常輕鬆地使用別人的充電線，即使這個充電線是其他的廠牌也完全沒有問題。

透過 MCP 協定解耦合

在了解了透過充電接頭作為案例來談耦合之後，我們回到技術的角度來看，在技術的設計或者程式設計上面，耦合這件事情會有什麼樣的影響。

這邊提一個最近在談 AI 一定會談到的重要概念 MCP。MCP 當時的推出，其實也是在做解耦合這件事情。

我們先看到過去在還沒有 MCP 這個統一的協定出現的時候，當 AI 的模型要去對接不同的外部工具，舉例來講，假設今天想要讓 GPT 的模型去對接到 GitHub 相關的工具，讓 GPT 的模型能夠幫忙我們去發 PR，或者是去根據 PR 的留言去幫忙修改程式碼。這些需要讓 AI 代理去跟 GitHub 做互動的外部工具，在過去的做法是用所謂的函式呼叫(Function Calling) 的方式。

這個函式呼叫的做法，每一個 AI 的模型廠商提出來的，都是專屬特定的函式呼叫。換句話說，函式呼叫的這個工具跟 AI 的模型彼此是耦合的。所以可以看到每一個模型，例如說 GPT 或者是 Gemini，它們對應的就是自家的廠商開發的這種函式呼叫的方式。所以假設今天某一個函式呼叫對應到 GPT 的模型，想要把它用到 Gemini 的模型就會沒有辦法用，因為它是跟 GPT 的模型耦合的。

所以從這個角度來看，開發的成本就會變很高。因為假設今天多一個模型，就需要多一個為這個模型去寫的函式呼叫的方法。所以從可維護性的角度來講並不理想。

當時 MCP 被推出，就是想要去解決這個問題。MCP 是一個協定，而透過這個協定，當今天開發了某一個工具，不管是哪一個 AI 模型，只要它有支援 MCP 這個協定，就像我們前面談的這個手機的案例，假設今天的這個手機不管是哪一個廠牌，假設它是支援 Type-C 的充電接口，那這樣子充電線都是可以互相通用的。

而在 MCP 的角度也是，假設 AI 的模型有支援 MCP 這個協定、這個接口，這樣子不管是哪一個模型，都可以去對接到相對應的工具。所以假設今天開發了一個 GitHub 的 MCP，它可以被用在不同的模型，或者是可以用在不同的工具，例如說用在 Cursor 或者用在 Copilot 這些不同的 AI 代理工具。

而這樣子就可以做到，只要開發一個 GitHub 的 MCP，就能夠用在所有不同的地方，而不用像左邊的這張圖，開發 GitHub 的函式呼叫(Function Calling)必須要針對每一個不同的模型，需要重複地寫很多相似，但是只為了不同模型去做稍微調整的程式碼。

所以可以看到，假設今天把工具跟模型之間的耦合拔掉，讓彼此之間的耦合變低，可維護性就會提高。

閱讀更多

如果讀者們想更了解耦合這個主題，並有具體的程式碼案例分析，以及低耦合在軟體工程其他面向的應用，我們在 E+ 成長計畫的主題文中，都有更詳細談。感興趣的讀者，可以在以下連結看到 E+ 的詳細介紹 (連結)。

本文為 E+ 成長計畫的深度內容，截取段落開放免費閱讀。歡迎加入 E+ 成長計畫閱讀完整版本 (點此了解 E+ 的詳細介紹)。