本篇文章更新時間：2025/12/30
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知。
一介資男的 LINE 社群開站囉！歡迎入群聊聊～
如果本站內容對你有幫助，歡迎使用 BFX Pay 加密貨幣 或 新台幣 贊助支持。
內容目錄
你不能設計自己不維護的系統：為什麼「懂程式碼的人」才能做真正的設計
編輯前言：這篇文章來自 You can't design software you don't work on，它點出一個軟體工程常被忽略的事實：軟體設計不是哲學辯論，而是一門建立在「對現有系統有深刻理解」的工藝。
核心觀點 (Key Takeaways)
- 真正有用的軟體設計必須建立在對系統細節的深入理解，否則就是空談。
- 「泛用型設計建議」在現實世界往往無用，因為大型系統的複雜度會直接限制你的可行做法。
- 架構師或高層若只做抽象設計，脫離一線工程，實際上無法對系統帶來真正價值。
深入解析
作者一開頭就講得很直接：只有每天摸系統的工程師，才能對設計做出有意義的貢獻。這聽起來像一句廢話，但現實中，太多人喜歡在不理解代碼的情況下發表設計意見——而這些意見通常都無法落地。
“When you’re doing real work, concrete factors dominate generic factors.”
換句話說，抽象的設計原則（例如 DRY、SOLID、hexagonal architecture）在大型現存系統面前，常常完全不敵那些「限制你能怎麼改」的細節。
作者列出三個我非常認同的現場觀察：
- 在大型 codebase 中，一致性比“好設計”更重要
- 現實系統充滿副作用與隱性耦合，它們讓你的選項極度有限
- 大系統永遠處於「半完成」狀態，因此你不能只看理想架構，要看改完之後「整體會變怎樣」
這些都不是書本會教你的，而是你每天 debug、每天 trace call stack 時自然會理解的事。
泛用設計什麼時候有用？
作者並不是否定所有 generic advice，而是強調它們的適用範圍：
- 在全新專案中（沒有歷史包袱）
- 在幾個可接受的方案中做取捨
- 在公司層級對齊技術選擇（如是否上雲、用 AWS 還是 Azure）
但即便如此，作者提醒我們：即使是公司級架構決策，也不能忽略現有系統的具體限制。否則就會做出「雲端完全不支援你需要的那個功能」這類災難式決策。
架構師與 local minima 的困境
文中對「高層架構師」的批評非常犀利。作者指出：許多公司讓最高薪的工程師專注做抽象設計，但這其實：
- 聽起來很棒，但不實用
- 很容易脫離真正的工程現實
- 設計者沒有風險，因此成敗都能輕鬆切割
“In practice, software architecture advice often has to be ignored by the people on the ground.”
我特別喜歡作者最後的主張：如果你負責系統設計，你就應該對結果負責。這不只讓責任更合理，也會自然地推動設計者真正深入理解系統，而不是停留在 PowerPoint 上。
筆者心得與啟發
這篇文章讓我重新思考了「軟體設計」真正的本質。很多工程師，包括我自己在早期，也常以為設計是「原則、圖表、抽象模型」的比賽。但隨著專案越大，我越能理解作者的話：設計其實是理解現狀、在限制下做最安全改動的過程。
如果你曾在大型 codebase 中推動改動，你一定懂：
- 你不是為了追求完美，而是避免把東西弄壞。
- 你不是在落實理想設計，而是在歷史包袱間找到一條可行小徑。
我會推薦這篇文章給所有正在轉往「架構師」、「Tech Lead」、「資深工程師」的人。它提醒我們：設計不是離開程式碼，而是更深入程式碼。
當你開始把設計視為一項「與實作密不可分的技能」，你才能真正成為能幫助團隊的工程師。