我們所熟知的 pull request 大約有 20 年的歷史，比許多現在捍衛其不可或缺性的人的職涯還要年輕。程式碼審查同樣感覺像是永恆的存在，但其實並非如此。Google 大約在 2006 年開始內部進行程式碼審查——許多早期的 Windows 軟體在發行時並沒有任何類似現代審查的流程。

程式碼審查現在已成為一個核准關卡，卻不再符合軟體工程工作的實際形態，而當我們即將再次改變它時，回想一下，我們最初正是自己發明了這項做法。它解決了特定的問題：在整合前捕捉缺陷、教導初階工程師，以及傳播知識以避免單一人士掌握所有脈絡。在發展過程中，它也逐漸變成合規、把關，以及在許多組織中的一種形式主義。

「程式碼審查卡在合併階段。AI 成為將其移到上游的驅動力。」

如今程式碼產量已打破這項做法，而困境不在於完全不閱讀程式碼與人類逐行審查 AI 生成的程式碼以避免產生劣質內容之間做選擇。而是關於程式碼審查原本的真正目的，並在機器撰寫大部分程式碼的世界中重建這些功能。

審查卡在合併階段

詢問任何人在哪裡進行程式碼審查，答案總是自動地指向：就在合併之前。不是之前，也不是之後。流程中的一個點，已成為唯一的一點。

在 Thoughtworks，trunk-based development、test-driven development 與 pair programming 被視為一種信仰，這意味著審查並非一場儀式。效益是在配對過程中持續產生，而不是數週後某人終於打開一個 500 行的 diff。當你不會在分支上停留數週，且測試已足夠時，綠色的管線大多就是你所需要的。

不應將整合前審查作為唯一審查地點的觀念並不新穎。過去缺少的是一股驅動力。如今我們擁有強大的代理式 AI 與協助我們產生更多程式碼的代理式 IDE，大家又開始重新思考此事。當一個代理可以在一個下午產出一個功能所需的程式碼時，你希望捕捉的缺口就移到了上游，也就是開發者向工具表達意圖的時刻。等到 diff 出現時，你審查的已是數小時前做出的決策所造成的後果，價值數千個 token。

「等到 diff 出現時，你審查的已是數小時前做出的決策所造成的後果。」

Aviator 的意圖驅動開發意指在意圖產生時加以捕捉。這可以是對範圍的簡要描述、明確排除的項目，或是一份驗收條件清單。根據我們的經驗，意圖最好直接從提示中捕捉，也就是工程師與代理合作時所做的決策。

我們現在究竟在審查什麼？

表達意圖會產生產出物。每個功能可能有數十個 Markdown 檔案、規格、澄清問題的記錄，以及隱藏在提示對話中的決策樹。大多數團隊都不會對這些內容進行版本控制。因此，值得進行程式碼審查的項目概念已經改變。

目前出現了三種陣營。有些團隊只審查規格，並信任其他部分。有些團隊則仍會審查每一項產出物——規格、程式碼以及中間的所有內容——清楚知道自己正在成為瓶頸。也有些團隊什麼都不審查，只測試實際運行的系統，因為產量之大讓他們別無選擇。

由於程式碼產量增加，團隊進行程式碼審查的方式也在改變。一個跨越五個以上檔案的 diff 已超出人類將預期變更與實際變更連結的能力。再乘以十倍。審查者現在想要的不只是 diff 與工單。他們想要看到原始意圖、代理採取的路徑，以及可能的程式碼。

閱讀意圖，而非實作

審查者不需要查看數百行程式碼來判斷它看起來是否正確，而是查看 10 行意圖與驗收條件，並思考一個問題：這是否以正確的限制條件解決了正確的問題？這對資深工程師來說是更好的時間運用方式。

這也讓審查的知識分享功能得以延續。知道平台中存在已使用多年的日期處理函式庫的審查者，可以將此知識編入組織的AI 劣質內容登記簿中，並且能完美地擴展。挖掘你過去 1,000 則審查評論、進行分群，並產生供人類核准的不變量候選。每個被編碼的不變量，都代表一則永遠不必再寫的程式碼審查評論。

集體程式碼所有權——沒有人應該掌握所有脈絡的概念——終於在實務上實現，因為脈絡必須離開人們的腦袋，才能對 LLM 發揮作用。

代理審查程式碼不需要使用者介面

目前大多數 AI 程式碼審查工具都建置在 GitHub 或 GitLab 之上，並留下評論。代理讀取評論、回應、推送變更，或為自己辯護。這與我們之前所做的形式主義相同，只是現在雙方都已自動化，而且不再需要介面。

無論是由人類或代理執行，程式碼審查都必須更早發生，而且甚至不必是審查。它可以是橡皮鴨除錯或教學時刻。盡可能將所有工作提前到最左側，以便後續需要做的工作降到最低。在生成過程中陪伴的諮詢或對抗式代理，在捕捉反模式形成時，其價值遠高於提交後才留下評論的代理。

我們在 Thoughtworks 建立了一個程式碼審查代理，最初是作為初階開發者的教學代理，指向團隊已知的原型與慣例文件，並被告知要解釋開發者偏離之處。後來演變為審查代理。

Aviator Verify 會啟動伺服器、傳送真實流量，並驅動 UI 互動，以檢查程式碼是否執行意圖所述的功能，而不僅是看起來正確。目標是提供審查者證據，讓審查變成「證據與意圖是否合理」的問題，而不是逐行閱讀 diff。

程式碼審查不會一夜之間演進

這一切不會透過組織-wide 備忘錄在一夜之間發生。你無法說服團隊放棄數十年來的信念；你必須在實務中展示。

Thoughtworks 的一位客戶曾有嚴格規定：顧問產出的任何東西都必須經過審查。後來一項規格驅動開發的試驗交給他們一堆 Markdown 檔案與異常大的變更集，而規定與現實發生衝突。他們自己得出結論：以傳統方式審查所有內容會讓他們成為瓶頸。

「驗證交給機器。判斷與知識留在人類手中。」

AI 劣質內容登記簿需要時間建立，在第一個月會感覺像雙倍工作：進行程式碼審查並建立不變量。但一旦編碼完成，劣質內容登記簿將不再需要審查者，並能防止相同錯誤再次出現。

驗證由機器執行，判斷由人類負責

形式改變了，但審查的原因並未改變。我們仍需要捕捉缺陷、教導下一位工程師，並讓決策保持可見。改變的是這些工作發生的位置。驗證交給機器，因為它們在這方面比我們更快、更一致。判斷與知識留在人類手中，因為這些是審查中對學習重要的部分。

因此，這項轉變並非從審查變成不審查，而是從閱讀程式碼轉變為閱讀意圖。

YOUTUBE.COM/THENEWSTACK

科技發展迅速，別錯過任何一集。訂閱我們的 YouTube 頻道，收看所有 podcast、訪談、示範與更多內容。

Group Created with Sketch.