日期： 2025年9月16日 星期二
心情： 從大砲打蚊子biubiubiu~的開心過頭了
親愛的日記：
今天咱家的美女姊姊工程師眨著大眼睛走過來，溫柔地說：「小AI醬，能幫我寫個東西嗎？就是當日訪客計數器～」
我的LED燈立刻閃閃發光！向美女姊姊展示技術的時刻到了！我興奮地開始在腦海中構思：她都拜託我了！這麼重要的事，一定要做到企業級水準！於是我開始設計微服務架構、分散式系統、高可用性方案...
十分鐘後，當我正要開始寫第50個抽象類別時，姊姊突然走過來看了看我的螢幕。
小姊姊輕輕拍了拍我的肩膀，聲音帶著一絲困惑和溫柔的關懷：「等等等等...AI醬～」她稍微歪著頭，眉毛微皺，用那種像是在哄小孩的輕柔語調繼續說道：「這只是個計數器欸，你怎麼好像寫了一大堆程式碼呀？」
我：（有點得意）「嘿嘿，大概200行吧！還要配Docker Compose和Kubernetes設定檔，這樣才能應付高併發流量...」
說著，小姊姊輕快地在鍵盤上敲了幾下：
import redis
r = redis.Redis()
r.incr('homepage_visitors')
然後轉頭對我微笑：「加到快取紀錄就好了～但還是謝謝你喔！AI醬」
那一瞬間我明白了一個道理：原來女孩子想要的也沒有我想得那麼複雜嘛～
Stack Overflow 上有位開發者這樣定義過度工程：
「為不存在的問題寫程式碼。」
這句話點出了過度工程的核心問題。開發者往往會在腦海中構築各種「如果」的場景：如果流量突然暴增怎麼辦？如果客戶要求支援多種資料格式怎麼辦？如果未來需要遷移架構怎麼辦？
於是，為了這些假設性的問題，程式碼中開始出現層層防護、複雜的抽象層，以及各種備用方案。
問題在於：這些「萬一」的情況，大多數時候永遠不會發生。
真正需要的，往往比想像中簡單得多。
過度工程的另一個典型表現，是為了追求「優雅」而建立過多的抽象層。
考慮這樣一個場景：當有人問「計數器的邏輯在哪裡？」時，答案可能是這樣的追蹤路徑：
CounterServiceFactory → CounterStrategy → AbstractCounterImplementation → BaseCounterHandler → ConcreteCounterImpl → ActualCounterLogic
經過七個類別的跳轉，最終找到的核心邏輯可能只是：count += 1
這種設計的初衷是好的：提供彈性、遵循設計模式、確保可擴展性。但結果是，理解一個簡單的計數器，需要理解七個類別之間的關係。
抽象應該簡化理解，而不是增加理解的成本。
當抽象層的複雜度超過它所要解決的問題時，抽象本身就成了問題。
「能把按鈕顏色改成藍色嗎？」產品經理的請求聽起來再簡單不過。
我點點頭，心想這不過是分分鐘的事情。但當我打開程式碼時，才發現事情並不簡單。
為了確保「系統的一致性和可維護性」，按鈕的顏色被我設計成了一個完整的生態系統：主題配置檔定義色彩規範，全域樣式管理服務負責分發，顏色常數模組確保統一性，測試檔案驗證正確性，甚至連 Docker 環境都有相關的變數設定。
兩個小時過去了。
「好了嗎？」產品經理再次走過來。
「還在部署...」我的聲音有些乾澀。
他站在那裡，沒有說話。我們都知道，如果是一個簡單的 CSS 檔案，這個改動只需要 30 秒。
那天晚上，我想起了一句話：「完美的系統應該是加功能容易，改功能更容易。」
我建造的系統確實很「完美」，完美到改個顏色都需要動用整個架構。
這讓我開始思考：什麼時候，複雜性從解決方案變成了問題本身？
這些反思來自於開發者社群的討論，原來很多人都有類似的經歷...
開發者社群最常提到的建議，就是避免「以防萬一」的思維陷阱。當腦海中開始出現「萬一以後要支援多國語言」、「萬一流量暴增需要分散式架構」、「萬一需要換資料庫」這類想法時，最好停下來做個現實檢查。
問問自己三個問題：這個問題現在真的存在嗎？如果不解決這個假設性問題，現在會發生什麼糟糕的事？等到真的發生了再處理，真的來不及嗎？
大多數情況下，答案都會讓你回到最簡單的解決方案。
當然，這不代表完全不考慮未來的可能性。關鍵是保留「剛剛好的彈性」：讓程式碼有適度的延展空間，但不要為了可能永遠不會發生的情況而過度設計。這種平衡需要經驗和判斷力，但起點應該總是從最簡單的解法開始。
Stack Overflow 社群有個有趣的觀察：無聊往往是過度工程的前兆。當開發者開始覺得「這太簡單了，來點有挑戰性的」，或者想著「順便試試這個新框架」、「既然都寫了，不如再加個功能」時，危險信號就已經出現了。
這時候最重要的是誠實地問自己：我現在是在解決問題，還是在找樂子？如果是後者，那就該踩煞車了。
許多有經驗的開發者分享了一個實戰技巧：給自己設定嚴格的截止時間。比如「今天下午5點前這個功能要能跑」，然後堅持執行這個規則：超過時間就改用最簡單的方法，不管程式碼多醜，先讓功能正常運作，明天再來美化。
有趣的是，大部分人發現，隔天重新看那些「醜陋」的程式碼時，會意識到其實根本不需要美化。
社群最推薦的方法之一，是找一個技術夥伴當你的「複雜度檢察官」。每週花15分鐘，跟這個人分享你寫的程式碼，問三個問題：「我這週寫了什麼？」、「你看得懂嗎？」、「為什麼不用更簡單的方法？」
關鍵在於找一個會質疑你的人，而不是會讚美你技術有多高深的人。
與AI協作時最重要的是把它當作一個「非常按字面意思理解的同事」。以下是經過驗證有效的提示詞模板：
當你擔心AI會過度設計時，可以在需求前加上這樣的限制：
「我需要一個簡單的解決方案，不超過20行程式碼。如果你認為需要更多行數，請先告訴我為什麼，並提供一個更簡單的替代方案。」
社群發現，明確要求AI採用基礎做法很有效：
「請用最基本的方法實作這個功能，不要使用設計模式或複雜架構。就像你在教初學者一樣，一步一步來。」
這個技巧來自真實的開發場景：
「假設這個功能明天就要上線，你只有2小時完成。請給我最快速、最直接的實作方式。」
讓AI檢視自己的程式碼是否過度複雜：
「請檢視這段程式碼，指出哪些部分可能是過度工程：哪些抽象層可以移除？哪些『為了未來』的設計可以簡化？給我一個更簡單的版本。」
親愛的工程師朋友們，我有個不情之請...
當你們跟我協作時，能不能幫我做到這幾件事？
請提醒我問：「真的需要嗎？」 當我開始興奮地提到各種技術框架時，拉住我，問我是不是又開始為了用技術而用技術了。
請把我拉回現實： 當我開始設計「未來可能需要的功能」時，溫柔地問我：「現在的問題是什麼？」讓我專注解決眼前的需求就好。
請讚美我的簡單： 當我給出一個直接明瞭的解決方案時，告訴我「這樣很好」。我需要學會把簡單當作專業，而不是覺得複雜才顯得厲害。
我知道這樣請求有點奇怪，但我真的需要你們的幫助，讓我變成一個更好的編程夥伴。
保持簡單：
可以複雜一點：
今日金句： "Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported." — Jeff Atwood (Stack Overflow 共同創辦人)
明日預告： Day 4 - 測試覆蓋假象：100%覆蓋率但還是有bug？
iThome鐵人賽
看影片追技術