.NET Walker

今天在 Build School 上課時發生了一件事，讓我想了想之後，還是決定寫篇文。 事情是這樣的。 上課時，我問學員：「如果有一個敏捷團隊，裡面大概 5-7 位成員，在一個迭代中同時開發 3-5 張需求卡片，你們覺得應該切幾個 feature branch?」 本來以為會聽到各種答案。 有人會按功能切、會按人頭切、或是按模組切…，因為我曾經聽過各式各樣的回答。 結果，他們所有人異口同聲：「只切一個分支。」 我愣了一下。「只切一個？」 「對，一個。」 這群學員才剛學 Git 沒多久，怎麼得出這個『違反常理』的結論的？上了這麼多年課，每次談到這個議題，學員都還可以跟我糾結半天，討論到底要不要用 Git Flow。 後來，助教跟我解釋，原來他們之前讓學員自己做了實驗。 什麼實驗? 實驗很簡單，因為反正要做專題，所以把學員幾個人分一組，讓他們用不同的分支策略跑幾個迭代。有些組按人切分支，有些按功能切，有些混著切。然後看看哪種方式最順。 結果呢？ 用多分支的組，第一個迭代還算順利，大家各寫各的，感覺井然有序。但整合的時候就開始出事了。功能 A 做完了，但要等 B 跟 C 才能 merge。有人幾天沒事做，只能坐著等。 到第二個迭代，問題更大。大家在自己的分支上寫了一段時間，最後 merge 時才發現衝突一堆。有些衝突好解，但有些是邏輯上的衝突，或是使用了同樣功能的不同套件，兩個人改了同一個模組的不同地方，單獨看都沒問題，合起來就爆了。 第三個迭代，有人開始崩潰。明明功能做完、測試也過了，但因為流程卡在 release branch，要等到迭代結束才能部署。一個小 bug 改了五分鐘，卻要三天才能上線。更慘的是，有人說：「程式碼寫完過了很久才整合，開始忘記當初為什麼要這樣寫了。」 最後，讓他們自己試試看：如果大家都在同一個分支上開發會怎樣？ 結果出乎所有人的意料之外。 衝突變少了(其實是變多了，但因為每天都在整合，有問題馬上發現，立刻解決，所以花在解決衝突的時間反而變少了)。部署變快了，一個小功能做完，就能立刻上線。整個團隊的節奏順暢很多，不用再有人乾等。 助教說：「他們自己體驗過就懂了，不用我們特別去教。」 聽完之後，我想了很久。 DORA 指標 其實他們體驗到的，就是 Google 研究出來的 DORA 指標在講的事情。 ...

開場 去年在 DevOps Days Taipei 研討會中，我有分享過類似的概念，當時我還無法實現。而且我覺得當時我提出這個想法的時候，很多現場聽眾目光裡閃爍著的，其實是略帶懷疑的眼神。 什麼概念呢? 我一直希望，能不能在 PR 過程中，Reviewer 只要寫下 Comment，就能有個 AI 工程師在背景直接幫我們改 code？ 或是能有一個夜班的 AI 工程師，可以隨時待命，接手白天人類的工作，在晚上完成一些例行性的任務。 現在，這個夢想終於實現了。而且比我想像的還要好用。 讓我們先聊聊 Git 版控時的 PR 流程。如果你有再用 Git 做團隊開發，我相信你一定知道 Pull Request 是整個開發協作的核心。開發者提交程式碼、reviewer 進行逐行檢查、留下 comment、來回討論、最後 approve 或是 request changes。這個流程很務實，也很必要。 但一直有一個問題。 不知道你有沒有算過，從 reviewer 在 PR 上留下 comment，到開發者真正動手修改，中間會經過多久時間？ 有時候是幾小時（如果大家都很閒），有時候是一整天（因為有會議、或其他工作），有時候甚至會拖到一兩天（可能是 Developer 沒收信、甚至根本是單純忘了上去看）。這段時間，PR 就這樣卡在那裡，什麼都不能做。CI/CD pipeline 也只能乾等。 更煩的是，有時候那些 comment 其實都是些「小修改」：改個函示名稱、加個錯誤處理、調整一下格式、補個註解。這種事情，說難不難，但要開發者停下手邊的工作、重新進入 context、再去改這些小東西，說實話，挺浪費時間的。 所以我一直覺得： 如果可以讓 AI 先做初步修改呢？ 那會如何? 主要不是為了取代開發人員，而是在 reviewer 提出建議後，讓 AI 先試著去處理那些「機械性」的修改。再由人類負責審核、判斷、給建議；AI 負責執行、修改、產出結果。這不是挺完美的分工嗎？ 實際操作 好，概念介紹完畢，來看看實際上如何運作。 假設今天有個 PR，reviewer 檢查後發現了一些需要改進的地方。就像平常一樣，在程式碼旁邊留個 comment。可能是「AI: 這一段應該要加上錯誤處理或Log」、「AI: 這個OOO變數名稱不夠明確」、「AI: 請加上OOO的...