🔧 阿川の電商水電行
如何在陌生的程式碼庫中快速找到方向——以及 Claude Code 如何幫助你在保持判斷力的同時站穩腳跟。
瑪格麗特是一位資深軟體工程師，而提摩西是她的初級同事。他們在倫敦一座宏偉的維多利亞式圖書館工作——在這種地方，館藏書籍都受到尊重，沒有人會假裝讀過他們沒讀過的書。今天，蒂莫西帶著別人的問題來了。
第六集
繼承
他一言不發地把印好的文件清單放在桌上。瑪格麗特像往常一樣，不慌不忙地從上往下讀，看著清單。
時間很長。
「這是誰的？」她問。
「那是馬庫斯的。他二月就離開了。這是一個計費整合系統——處理訂閱續訂、按比例計算費用、付款重試和 webhook 處理。」他停頓了一下。 “沒有文件。有一些註釋，但大多數都描述了程式碼的功能，而不是為什麼它這樣做。”
“那你需要用它做什麼呢？”
“新增對新支付服務商的支援。產品團隊希望月底前完成。”
瑪格麗特還在看著文件清單。 “你盯著它看了多久了？”
“從星期一開始。”
今天是星期四。
“是的。”
她放下紙。 “告訴我你目前理解了什麼。”
「入口點很清晰。webhook 處理程序也很清晰。但中間某個地方有個按比例分配的引擎，我實在搞不懂。變數名稱…很含糊。有些函數會呼叫其他函數，而這些函數似乎又會回調到前面的函數。」他看著她。 “我不知道該從哪裡入手。”
「你一開始就選錯了切入點，」瑪格麗特說。 “這就是我們今天要討論的內容。”
為什麼不熟悉的程式碼難以閱讀
瑪格麗特說：“大多數開發人員對待不熟悉的程式碼，就像對待一本別人翻到第200頁的小說一樣。他們試圖理解自己正在閱讀的那一頁。由於缺乏上下文，他們會感到困惑。他們翻回前面幾頁，結果更加困惑，然後得出結論：程式碼寫得很糟糕。”
“它可能寫得很糟糕。”
「也許是這樣，」她承認道，「但這個結論是之後才需要得出的。首先，你需要認真閱讀程式碼。」她拿起筆。 “人們在閱讀不熟悉的程式碼時常犯兩個根本性的錯誤。第一個是從中間開始讀起。第二個是在還沒弄懂任何東西之前就試圖理解所有內容。”
蒂莫西看了看文件清單。 “兩件事我都做了。”
「大多數人都會遇到這種情況。讓你感到困惑的按比例分配機制——你知道它究竟是真的很複雜，還是僅僅因為你不知道它的作用才覺得它複雜嗎？”
他沉默了一會兒。 “我不知道。”
「答案正確，」瑪格麗特說。 「這說明了一個重要的道理。你無法評估你還沒有模型的程式碼。在嘗試理解按比例分配的邏輯之前，你需要了解按比例分配在這個系統中的作用。不是程式碼本身，而是它的行為。”
兩次傳球
瑪格麗特說：“在打開程式碼之前，你需要進行兩遍檢查。大多數開發者都忽略了這兩遍檢查，結果為此付出了代價。”
她把記事本轉向他。
「第一遍是映射階段。你讀的不是程式碼，而是結構。文件名、目錄結構、事物的頂層形態、函數名——不是函數體，只是函數名。這個程式碼庫認為什麼重要？它的概念是什麼？它選擇給哪些事物命名？”
“我查看了檔案名稱。”
你把它們寫下來了嗎？
他沒有。
「把它們寫下來，」瑪格麗特說。 「建立一套詞彙表。如果你看到prorateCharges 、 applyCredit 、 calculateMidCycleDelta這些都是概念。在你閱讀任何一行實現程式碼之前，你應該能夠用系統自身的語言來描述它。」她停頓了一下。 “這就是 Claude Code 真正發揮作用的地方。它不是幫你讀程式碼，而是幫你建立理解圖。”
“如何？”
你貼上程式碼結構，包括檔案名稱、函數簽名和類別名稱。然後，基於這些名稱和程式碼庫的組織結構，描述你認為這個系統的功能、主要概念，以及在加入新功能之前你想先解答哪些問題。你得到的並不是一個確切的答案，而是一個假設——一個初始模型，你需要在閱讀過程中進行測試和完善。
提摩西仔細地把這些記了下來。
「第二遍是流程分析。你選擇系統中的一條完整路徑——一筆交易、一個 webhook 事件、一次續訂——然後從入口到出口跟踪它。不是所有事情，而只是一件事。你是在追踪一個線索，而不是在讀一本書。”
“還有克勞德·科德？”
「方法一樣。貼上相關文件，描述你想要遵循的路徑，然後問自己：這段程式碼在這條路徑上做了什麼，這條路徑通向哪裡？再說一遍——這是一個假設。你是在建立模型，而不是在等待一個結論。”
假設模型
「我想把一件事說清楚，」瑪格麗特說。 「當你用 Claude Code 讀取不熟悉的程式碼時，它給出的只是一個假設，而不是事實。它只能讀取程式碼中的內容，卻不知道當初做出這些決定的原因。它不知道哪些需求曾經存在，而現在又不存在了。它也不知道在有人更新程式碼卻沒有更新註解之前，函數上方的註解原本寫了些什麼。」
“它會原樣讀取程式碼。”
「沒錯。這比你現在掌握的資訊要多，但還不足以了解全貌。」她目光堅定地看著他。 「這就是紀律。你要接受克勞德·科德提供的訊息，並將其作為提問的起點，而不是答案。如果它說這個函數通過比較計費週期剩餘天數和總天數來計算按比例分攤，你的反應不應該是‘太好了，我現在明白按比例分攤了’ 。你應該問的是：對於這個產品的方法來說，這一點是這樣的方法嗎？
「用實際程式碼進行測試。使用真實輸入執行。找出閱讀文件沒有揭示的邊界情況。Claude Code 可以幫助你產生這些測試——給定這種比例分配邏輯，哪些輸入會暴露錯誤行為？但最終由你來決定這些測試是否提出了正確的問題。”
如何處理中間部分
“中間那部分，”蒂莫西說，“我搞不懂的那部分。我具體該怎麼做呢？”
「中間部分總是最難的，」瑪格麗特說，「因為當你讀到那裡的時候，程式碼會假定你了解你並不具備的背景資訊。你缺少決策的詞彙——為什麼事情會那樣做。」她放下筆。 “你可以做三件事。”
「首先，從已知部分入手。你說你很清楚 webhook 處理程序。那就從那裡開始。webhook 處理程序呼叫了什麼？追踪這個呼叫。不要糾結於它最終指向哪裡，只需追踪下一步即可。從穩定的狀態出發，一次處理一個函數，逐步建置理解。”
蒂莫西緩緩地點了點頭。他一直在試圖孤立地理解中間部分。
「第二點——閱讀測試案例。如果有測試案例——值得稱讚的是，Marcus 確實編寫了測試用例——它們就是文件。它們從外部描述了行為。例如，如果一個測試用例指出，當訂閱週期中途升級時，按比例計算的費用應等於每日差額乘以剩餘天數，那麼這個測試案例比實際實現更能體現設計意圖。」
「馬庫斯確實寫了試卷，」提摩西說。 “我瞥了一眼。”
「不要只是匆匆一瞥，要認真閱讀。它們是對程式碼預期功能最清晰的闡述。」她稍作停頓。 「當你把這些測試用例——不是實現，而是測試用例——拿給 Claude Code 看，問問他：這些測試用例定義了哪些行為？是否存在它們沒有涵蓋的情況？ ——你就能得到一些寶貴的東西。你會得到一份對規範的獨立解讀。”
“第三件事呢？”
「你要明白，中間有些部分在你做出改變之前是無法理解的。」她看著他。 「光靠閱讀是無法理解的。在某個階段，你必須在執行測試套件的本地環境中進行一些小的、可逆的更改，觀察哪些地方出了問題，讓這些問題教會你閱讀無法提供的東西。這不是猜測，而是有條理的實驗——但只能在測試框架下進行，絕不能針對那些無法回滾的程式碼進行實驗。尤其是在收費系統中的損失
他主動把那句話寫下來了。
「你先提出一個假設——這個函數負責產生 x——然後做出一些改變來檢驗這個假設是否正確，最後觀察結果。測試套件就是你的安全網。不要在沒有它的情況下進行實驗。”
信任問題
「我對這段程式碼的信任度有多高？」蒂莫西問。這個問題一直縈繞在他心頭，揮之不去。
瑪格麗特想了想。 「你信任它，就像信任一張你從未去過的城市的地圖一樣。它很可能大部分都是準確的。但有些地方可能已經過時了。有些路可能存在但地圖上沒有，而有些路在地圖上卻已經不存在了。你用它來導航，但你也會抬頭看看實際情況。」
“那麼克勞德·科德對密碼的解讀呢？”
「一樣。總比沒有強。但不如你自己建構的理解更有權威性。」她端起茶杯。 「關於信任，我想特別跟你說的是：容易理解的程式碼——可以暫時信任，但要驗證特殊情況。難懂的程式碼——在你弄明白它難懂的原因之前，千萬不要信任它。”
她小心翼翼地放下杯子。
「難以理解的程式碼有時是開發者的巧妙構思——他們精通程式語言，並力求簡潔。有時，它是過去多年決策累積的痕跡，這些決策在當時看來合情合理，但隨著時間的推移，最終掩蓋了最初的輪廓。偶爾，它也可能是一個真正的錯誤，只是因為沒人願意仔細檢查而無人發現。」她停頓了一下。 「尤其是在計費系統中，有時以上情況都不是。它關乎合規性。稅法因司法管轄區而異。支付處理商施加的限制缺乏業務邏輯解釋。PCI 要求會在程式碼中留下痕跡，在一看似乎毫無章法，但當你了解它們是為了防止什麼時，這些痕跡就顯而易見了。乍一看似乎毫無章法。
“我該如何查明呢？”
「提交歷史，」瑪格麗特說。 “這讓我想起了我之前應該說的話。”
在他離開之前
外面，倫敦的午後天氣一如既往地保持著堅定的中立狀態，既不陰沉也不晴朗。
“你說我一開始就走錯了方向，”蒂莫西說，“那我應該從哪裡開始呢？”
「從一開始，」瑪格麗特說，「不是從文件的開頭，而是從你理解的開始。」她看著他。 「你第一天應該完全不要看程式碼，而是去了解系統的功能，以及產品文件（如果有的話）。然後是提交歷史——不僅僅是提交訊息，還有它們的模式。哪些文件同時被修改，哪些函數被反復修改。一個兩年內修改了十五次的文件，肯定是在試圖告訴你一些事情。一個函數，如果它的提交訊息寫著“緊急修復：歐盟年度
“我一個也沒看。”
「拉取請求也是如此。當 Marcus 為按比例分配引擎的更改提交拉取請求時，該拉取請求中的討論——審查者提出的問題、Marcus 給出的理由、合併前的反复溝通——這些就是從未出現在評論中的文件。大多數開發人員根本不會閱讀這些內容。這就像坐在程式碼編寫者旁邊一樣。」
“所有這些東西都在儲存庫裡。”
「全部，」瑪格麗特說。 「Claude Code 可以幫你理解這一切——貼上提交記錄或 PR 描述，然後問問自己：這個改動試圖解決什麼問題？它做了哪些假設？歷史記錄就是決策的記錄。決策有其原因。你需要的就是這些原因。”
他慢慢地收拾東西，就像他還在思考某件事時那樣。
“還有一件事，”瑪格麗特說，“當你真正理解了——當你建置好模型並測試完畢，並且感覺有把握的時候——把它寫下來。不是為了馬庫斯，也不是為了你自己。而是為了將來繼承這段程式碼的人。”
她目光堅定地看著他。
“因為他們將來也會站在你現在站的地方。在他們找到立足之地之前，他們不應該經歷三天迷茫期。”
他合上了筆記本。
室外，倫敦的午後依舊炎熱。圖書館裡，一位開發者剛領悟到，閱讀自己未曾編寫的程式碼，與其說是考驗聰明才智，不如說是考驗耐心──而出發前繪製的地圖，才是接下來旅程得以順利進行的關鍵。
下一集：瑪格麗特和蒂莫西將探討你不熟悉的語言——如何處理用不熟悉的語言編寫的程式碼庫，以及當你的專業領域之外時，Claude Code 能做什麼和不能做什麼。
《克勞德·科德的秘密生活》隔天在 tech-reader.blog 上更新。
如果本系列文章對您有用，請分享給需要接手他人程式碼的開發人員。
Aaron Rose 是軟體工程師，也是tech-reader.blog的科技撰稿人。想觀看解說影片和收聽播客，請造訪Tech-Reader 的 YouTube 頻道。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
