我買齊了 Clean Code，卻越來越少看 Code

我幾乎把市面上那些談 Clean Code、Clean Architecture 的名家著作都買齊了。

以前很喜歡讀這些書。命名、函式大小、責任劃分、依賴方向，每個原則都想弄懂，也想用在自己的程式裡。寫完之後，看著整整齊齊的 code，會有一種很具體的滿足：這段是我整理出來的，我知道它為什麼長這樣。

那些原則背得熟，真的會覺得自己很強。

但現在，我越來越少看 code。很多實作交給 AI，自己也不再逐行雕琢。這讓我開始想：以前買的那些書、花的那些時間，還有用嗎？Clean Code 是不是死了？

招式不用了，內功還在

我覺得這有點像，你以前練過化骨綿掌，後來有了機關槍，就不一定還要靠掌法解決問題。但九陽神功的內功還在體內。

讀過的書、改過的爛程式、追過的 bug，不會因為工具換了就消失。它們慢慢變成你判斷事情的方式，有時候甚至不需要刻意想起哪本書、哪一條原則。

AI 提出一個方案，我還是會問：這裡為什麼要拆？這個狀態由誰負責？中途失敗後，系統還記不記得剩下的工作？它說成功，究竟是哪一步成功？

這些問題不是用了 AI 才突然會問的。以前花在程式上的時間，讓我知道哪些地方容易出事，也讓我對某些看起來很完整的答案，還是會多追問一句。

從前走過的路沒有浪費。只是現在，不需要每次都把整套掌法重新打一遍。

就算有 AI，還是得注意權限、交易、重試和資料一致性。這些當然都要注意，但以前本來就要。

差別是，以前我常常得先花很多時間確認基底好了沒：程式能不能跑、結構合不合理、錯誤有沒有處理、測試寫完了沒。光是把這些整理好，就已經用掉大半的力氣。

我也知道應該往上看。整個流程合理嗎？服務接起來之後，會不會互相拖累？使用者遇到失敗時，究竟看見什麼？但知道要看，跟真的有時間看，是兩回事。

現在 AI 接手了一部分實作，我終於能把更多注意力往上移。

查 MQTT 認證問題時，我關心的是 CPU、資料庫連線、timeout 和裝置重試怎麼串成一個循環。看 Kafka 時，我會追問程式回報的成功，到底代表排進佇列、broker 收到，還是後面的工作也完成了。

這些事情最後仍然會回到程式，但我閱讀的起點改變了。我先追一個系統問題，再沿著需要確認的地方往下看。以前學過的東西，幫我決定從哪裡查起。

以前我最喜歡的事情之一，就是看自己整理得漂漂亮亮的 code。

把一個很長的函式拆開，把模糊的名字換掉，讓責任和依賴各就各位。整理完再看一遍，心裡會很舒服。那裡面有自己的手藝，也有自己對好程式的理解。

現在很多程式不是我一行一行寫出來的。即使結果能用，那種親手完成的滿足，也不會完全一樣。有時候我甚至還沒來得及享受某個小地方寫得很好，就已經開始處理下一件事。

這部分我確實有點捨不得。

只是我的焦點也換了。尤其有了 AI agent，圍繞一個目標，能一起推進的事情越來越多。查資料、比較方案、做實作、跑測試、整理結果，原本得由我依序完成的工作，現在有些可以同時進行。

我花更多時間決定要做什麼、哪些工作可以一起做、哪些必須等前面的結果，以及最後拿什麼證明它真的完成了。看到這些工作接起來，讓一個原本很難推動的目標逐漸成形，是另一種樂趣。

當然，同時做的事情多了，也會多出新的問題。每個 agent 都說自己完成了，接起來卻可能對不上。有人根據舊資料修改，有人測的是另一個版本。這時候，我得回頭確認它們各自做了什麼，不能只收下幾句「測試通過」。

我現在很少像以前一樣，寫完程式後逐條對照 Clean Code 的原則。也不再覺得每個地方都值得花同樣的時間整理。

但我沒有覺得那些書白買了。

它們讓我建立過一套理解程式的方式。現在實作變快了，我可以帶著這些經驗，把時間放到以前來不及看的地方。需要追進程式時，我也還知道怎麼往下走。

我仍然喜歡漂亮的 code，也會懷念親手把它整理好的感覺。只是現在，讓我興奮的事情變多了。我開始想看看，帶著以前練出的內功，加上這些新工具，自己到底能把事情做到多遠。