Design Pattern 在 AI 時代還有用嗎?
你是否發現 AI 生成的程式碼,每次整合都要花大量時間重新改寫?自從 Coding Agent 被推出,就不斷有會聽到軟體工程師會被取代的聲音。然而,最近跟同事協作的過程中,整體還是符合「剩下專業的人留下」這樣整體的現況。
可能有人會認為有 Coding Agent 後「不用學習軟體開發」但沒有意識到,許多高階的軟體開發知識,都不是「實作」的問題,更多是怎麼「設計」或者「架構」
可維護性
在我的開發經驗中,大部分軟體開發的知識都是在解決「如何維護軟體」這個問題,如果用非常簡單的說法,其實就是「怎樣更好修改」
舉例來說,寫測試是為了修改的時候不會加入 A 功能,但原本的 B 功能就不能正常使用,測試會確認兩個功能在範圍內(如:單元測試的範圍)都能正常運作。
同樣的重構(Refactoring)大多也是為了往後的修改而準備,架構理論也是要讓長期擴充功能更容易,基本上大部分軟體交付品質的判斷,很高機率都跟「能不能繼續修改」有關,就算是 Design Pattern 也是把常見的設計方式整理起來,終究還是回到「容易修改」的問題上。
回過頭看 Coding Agent 的表現,雖然可以用遠超人類的速度產生程式碼,即使現在的「正確性」已經達到大多數工程師都會說「交給 AI 實作就好」這樣的評價,但軟體的設計、架構仍然只是隨機拼湊的,不一定總是容易修改、維護。
基礎能力
在 AI 時代中,身為軟體工程師的能力不再是「背誦」的性質,我們不需要了解所有程式語言的語法是怎麼使用、每一種軟體開發的理論的實作細節。
但是,對於 SOLID 原則、Design Pattern、Clean Architecture 以及所有關於軟體設計的理論,至少要熟悉到在對應的情境時可以馬上想到「這裡很像這個」或者「這裡該使用這個」才足夠對應軟體開發所需的能力。
以工作當作案例,我跟同事個別負責兩個不同的專案,但是最終需要整合在一起進行驗證。我們都有使用 Coding Agent 來進行開發,但是一直困擾我的是每一次拿到新的檔案,我必須讓 Coding Agent 重新改寫過一遍才能使用。
如果只是在 Vibe Coding 或者利用 ChatGPT 或 Gemini 的 Canvas(畫布)製作小工具,這可能還在接受範圍,但是以打造產品來說,這樣做就失去了原本 AI 幫助我們快速開發的意思,這變成我只是拿到一份 80 分的文件,重新實作一遍。
所以我跟同事花了一點時間,做了一些調整
- 確認介面
- 抽象處理
聽起來似乎不難,但這都是軟體開發基本功的應用。在規格中,我跟同事的實作只會有 Get 和 Create 兩種情境,但之前「曝露細節」太多給我,確認介面就是在區分每一個設計哪些應該「封裝」起來不被外部使用。
接下來我們需要處理應用情境,因為我負責的是一個檢驗的系統,用來確認同事的實作跟設計一致,這樣才能繼續部署到正式環境,為此我們需要檢驗環境的特殊行為,前面確認介面的地方再次發揮作用,因為我們可以利用依賴注入(Dependency Injection)來抽換用於驗證還是正式服務的行為。
在更近一步,因為同事的實作對我來說只能有 Get 和 Create 被暴露,所以我們應用了 Design Pattern 中 Factory 的 Creation Method 提供一個非常簡單的 build_local_runtime(...) 方法來讓驗證專案的整合變得簡單。
這部分看起來非常像寫測試,但我們的專案也是跟 AI 領域有關的,所以不太能使用傳統的方式測試,因此採用了不同的機制處理
很明顯的,如果只是讓 Coding Agent 直接去實作,如果缺乏事前的設計或者引導,是很難將這些細節處理完善的,這也是軟體開發的基本功即使在 AI 時代仍是非常有價值的原因,一定程度上也能減少大量 AI 反覆修改的頻率,畢竟原本就能很好的提升人類開發的速度,搭配上 AI 就能更大地提高速度。
設計驅動
在 AI 時代之前,軟體開發有很大一部分是由開發時程決定上限,因此寫得又快又好的工程師幾乎是最理想的,但現在速度上限是人類的狀況下,好的設計反而更有價值。
還記得在去年的時候,我跟同事分享「內聚(Cohesion)」可能是未來一個很重要的概念,以往我們只關注「耦合(Coupling)」的問題,努力在避免耦合,卻很少關心我們是否把相關的實作內聚在一起。
為什麼要內聚呢?因為這樣更適合 Coding Agent 修改,假設我們的設計達到非常理想的狀況,每一次讓 AI 做修改時都會剛好的根據規格找到特定的檔案,檔案中又剛好包含所有需要修改的部分,就很自然的可以在較少的步驟(搜尋、讀取)完成編輯。
當大家都很快的時候,這類小細節反而能夠成為更快的要素。這也變成一個很有趣的現象,過去我們不願意花時間思考、討論去釐清,是因為被時間追著跑需要不斷往前推進,但現在花更多時間釐清跟討論,可以得到一個開發更快、更穩定的系統,因為好的設計對 Coding Agent 來說也更不容易出錯、修改也更容易可控。
這也是為什麼像是 Design Pattern 這類基本功非常重要的原因,如果我們對這些知識足夠熟悉,只需要判斷在怎樣的時機引入適當的設計,就可以非常接近以往人類花費大量精力製作的高品質軟體,但又變得更快更省力。
這一切的前提,都還是在對該領域的專業有足夠的認識,單純依靠 AI 擁有的知識仍不足夠。專業的人留下,正是因為這些基本功無法被取代。
喜歡這篇文章?請我喝杯奶茶 🧋