AI也造代碼屎山!研究發現GitHub Copilot代碼可維護性差,偏愛“無腦重寫”而非重構復用已有代碼
AI幫忙寫代碼程序員用了都說好,但代碼質量真的靠譜嗎?
結果或許令你大跌眼鏡。
一家名為GitClear的公司分析了近四年超過1.5億行代碼后發現,隨著GitHub Copilot工具的加入,代碼流失率(即代碼寫入后不久又被返工修改、刪除的情況)出現了顯著上升:
2023年為7.1%,而2020年時僅為3.3%,翻了一番。
與之相應的,代碼復用率也出現了明顯下降。
言外之意,AI寫的很多內容其實不亞于“屎山”,根本不好隨著業務的變化作相應更改。
看起來,AI編程工具還遠沒有宣傳中的那么好用?
Copilot更愛直接添加代碼而不鼓勵復用
GitClear收集的1.5億行代碼中,有2/3來自匿名私企,剩下的1/3則源自于谷歌、Meta和微軟的開源項目。
它們全部被排除了“噪聲”數據,比如在多個分支中提交的一模一樣的代碼、空行以及其他沒有意義的代碼行。
調查的主要對象是微軟的GitHub Copilot。
它于2021年6月推出測試版,按照CEO說法,截至2023年第三季度,該工具已有超100萬開發者付費訂閱,能夠幫助開發者編寫46%的代碼,并將編碼速度提高55%。
不過在此,GitClear不關心編碼速度,只關心質量。
“AI編程工具更類似于高級開發人員,仔細又精細?還是更像短期承包商一樣,只在乎面前的任務完成與否?”
為此,他們統計了這1億行+代碼的新增、刪除、更新、移動、復制/粘貼等情況,得出了這樣一個趨勢表格:
從中我們可以發現:
Copilot添加代碼、復制/粘貼代碼的百分比比更新、刪除和移動增加得更明顯。
其中我們還可以清晰地看到,移動代碼的百分比從2020年的25%下降到了13.4%,這是所有數據中唯一一個反向特例。
更少的移動意味著更少的重構和復用,加上大幅增長的添加、復制/粘貼代碼,這表明:
AI編程工具并不鼓勵代碼復用、在已有代碼上進行修改,而是更傾向于“無腦重寫”。
在此,GitClear也指出,過度新增代碼、復制/粘貼對代碼的長期可維護性也相當不利。
這其實在人類程序員中也是老問題,可能是程序員覺得解決當下問題比思考如何復用、整合現有代碼更快更容易,也可能是因為同個項目組中的開發人員溝通不暢等。
遭殃的就變成后面的維護人員。
Copilot的代碼質量下降也體現在代碼流失率(Churn)這個數據上。
在此,它的標準定義是代碼編寫后不到兩周的時間內修改更新的百分比。
表格顯示,2020年的流失率為3.3%(那會還沒有用上Copilot),2023年增長到5.5%。
GitClear預計,2024年將直接相比2020年翻一番之多,達到7.1%。
這說明AI的加速,并沒有帶來足夠高質量的代碼。
除了以上結論,GitClear還發現,Copilot的代碼建議算法還被設計為總是提出最有可能被用戶接受的建議——
這選擇乍一聽沒啥毛病,但其實會忽略代碼簡潔易讀的重要性。
總的來說,這項結果足以讓那些擔心AI編程工具會取代人類程序員的人暫時把心放肚子里。
最近也有不少其他研究佐證了GitClear的發現。
比如來自CodeScene的一篇報告就表示:
在編碼任務中,AI遠無法取代人類;今天的AI太容易出錯,且遠未達到能夠安全修改已有代碼的程度。
網友體驗大差不差
實實在在使用過Copilot的人怎么說?
一位網友表示:
我用了倆個月后取消了會員,因為花了太多精力去檢查AI給出的代碼以及修復bug。
在TA看來,現階段還是自己編寫內容要省力得多,因為自己知道自己想要寫什么,修復自己的bug總是比修復機器人的更容易。
有人使用的是ChatGPT而非Copilot,也對TA的話表示了贊同:
我對AI的能力感到驚訝,但還是不會稱其為“好代碼”。
當然,Copilot在大家眼里也并非一無是處。
一位從事web開發20多年的程序員就表示:
用它編寫重要的SQL或TypeScript代碼時,總是失敗;但對于編寫測試、請求處理、React樣式等等來說,它還是可以幫我節省大量時間的。
你的Copilot(或者其他AI編碼工具)體驗如何?你同意GitClear的發現嗎?