點選上方↑↑↑「OpenCV學堂」關註我
來源：公眾號 新智元授權
【導讀】 想不到，AI生成的內容影響數據品質的問題，已經在程式碼上出現了。最近，GitClear釋出的一項調查報告顯示，用AI寫程式碼，正在導致「全球程式碼品質面臨下行趨勢」。
AI正在使全球的程式碼品質下降！
最近，GitClear釋出的一項調查報告顯示，用AI寫程式碼，會讓程式碼的品質和可維護性不斷下降。
這引起了全網熱烈討論：
「借助AI提供商，您可以將程式碼生成速度提高50%（即使是您不理解或無法編寫的程式碼），但代價是程式碼的品質和永續性不斷下降。」
「我們要追求的，到底是品質還是速度？」
調查中，GitClear分析了從2020年1月到2023年12月之間編寫的1.53億行程式碼更改數據，
——1.53億行程式碼，是目前已知最大的用於評估程式碼品質差異的數據集。
調查發現了什麽？我們先看下面這張圖：
圖中展示了4年中的程式碼改動率——編寫後不到兩周就被撤銷或更新的程式碼行百分比，——深色部份表示受AI程式碼生成工具影響的時間。
調查中同樣發現，「新增程式碼」和「復制貼上程式碼」的比例相對於「更新」、「刪除」和「移動」程式碼的比例在增加。
這貌似說明開發人員在大量使用Copilot等AI程式碼生成工具，快速生成了大量程式碼，但隨後發現了程式碼中的問題，——GitClear的報告預計在2024年，這個程式碼改動率將達到2021年AI出現前的兩倍。
另外一點就是，AI程式碼生成工具不太理會人類程式設計師的一些原則（比如「重復造輪子」這件事），也就造成了程式碼庫中越來越多的重復程式碼。
——不過很多碼農都是「CV程式設計師」，這樣看來，AI也算是學到了精髓。
2023年，GitHub Copilot大放異彩。在短短不到兩年時間內，這款AI編程助手從一個「原型」迅速成長為「核心工具」，被全球數百萬開發者在數十萬家企業中廣泛套用，開啟了coding的新時代。
對此，GitHub發表了多篇研究論文，探討了AI在軟體開發領域的增長與影響。
速度提升55%，GDP增加1.5萬億
研究表明，使用Copilot的開發者編碼速度可以提高「55%」，導致總的程式碼量增加了46%，並且為全球創造了1.5萬億美元GDP。
有了這樣的成績，也就不難理解為什麽GitHub的CEO Thomas Dohmke，會在繁忙的工作之余，專門撰寫關於AI革命的文章。
在2023年2月Copilot個人版使用者超過一百萬之後，GitHub又推出了GitHub Copilot for Business版本。
那麽，有多少開發者在用AI來編寫程式碼呢？
GitHub與Wakefield Research在2023年6月的一項研究中指出，92%的美國大型公司的開發者表示他們使用了AI編程工具。並且有70%的開發者認為使用AI帶來了明顯的好處。
不過，O’Reilly Publishing在2023年8月給出的調查數據顯示，67%的開發者沒有用過ChatGPT或Copilot。不管怎樣，GitHub在市場上仍有巨大的潛力等待挖掘。
——然而，大語言模型（LLM）生成的程式碼引發的一個問題是：
這些程式碼的品質和可維護性到底怎麽樣？
面對AI滔滔不絕吐出的一大堆程式碼，程式設計師似乎不太容易發現其中的問題——畢竟都不是自己寫的。
還有，眾所周知，當程式設計師接手前人留下來的*山程式碼時，應該遵守的「潛規則」是：
如果這個程式碼能夠正常執行，就千萬不要妄想去重構。
AI生成程式碼背後的挑戰
無法否認，Copilot實實在在的提升了開發者的編碼效率。GitHub的研究顯示，使用Copilot的開發者滿意度提升了75%。
做初期產品開發的人是滿意了，可後面負責長期維護的人就蛋疼了。
資深程式碼研究者Adam Tornhill（著有【程式碼即犯罪現場】）對此持保留態度：
使用Copilot可以使程式碼編寫速度提高55%，但如果是本就不應該編寫的程式碼呢？
如【Clean Code: A Handbook of Agile Software Craftsmanship】一書的作者Robert Martin所說，程式碼的閱讀時間是編寫時間的十倍。快速編寫糟糕的程式碼，意味著給後來的程式碼閱讀者帶來了巨大的負擔。
此外，AI程式碼助手還帶來了其他問題：
比如程式碼助手擅長生成程式碼，卻不擅長修改；當有多個生成工具給出建議時，評估哪個更好是很耗費時間的；
最後，AI程式碼助手與開發者的動機可能不同，對於程式碼最佳化來說，AI往往傾向於提出最有可能被接受的建議。
所以，相比於經驗更豐富的開發人員，初級開發者更傾向於接受AI給出的程式碼建議：
而老鳥們深知，隨著時間推移，程式碼的維護成本會越來越高。
程式碼操作介紹
GitClear將程式碼變更分為七個類別（研究中涉及前六種）：
1. 新增程式碼：首次送出的程式碼行，程式碼行是全新的，不包括對現有程式碼行的小幅修改，也不包括那些被添加、移除後又重新添加的程式碼行。
2. 刪除程式碼：被刪除並送出的程式碼行，且至少在隨後的兩周內未被重新加入。
3. 移動程式碼：將一行程式碼剪下並貼上到新檔或同一檔內的新函式中。「移動」的操作僅涉及位置的變換，程式碼內容不發生改變。
4. 更新程式碼：修改大約三個或更少的單詞來更改原有程式碼行。
5. 尋找/替換程式碼：從三個或更多位置移除相同字串，並用一致的內容進行替換。
6. 復制/貼上程式碼：在一次送出中，將相同的程式碼行內容復制到多個檔或函式中。
7. 無操作程式碼：指一些微小的程式碼變更，比如空格或同一程式碼塊內行號的變化。
GitClear自2020年起根據這些操作對git倉庫進行分類，並在Diff Delta文件中提供了程式碼操作的具體範例。
截至2024年1月，GitClear分析並分類了大約十億行程式碼，這些程式碼來自商業客戶（如 NextGen Health, Verizon）和流行的開源倉庫（如 Facebook React, Google Chrome）。
其中，1.53億行程式碼為有意義的變更，被用於本研究。
最後，還有一個單獨的定義叫做「攪動」（churn），意思是程式碼被建立、推播到git倉庫後，在接下來的兩周內被撤銷或大幅修改。
——也就是咱們最開始分析的那張圖，可以將「攪動」理解為，作者一開始編寫、送出並推播到公司git倉庫的程式碼有問題，後來發現了。
數據分析
下表根據GitClear的數據，分析了不同的程式碼行運算元量，並按照程式碼的編寫年份進行分類。
表中的前六項就是上面提到的程式碼變更的前六個類別，而最後一項是「攪動」。
將表格數據繪制成下面的圖表，可以更清晰地看出各種程式碼操作型別的變化趨勢，比如，圖表中的淺藍色細線顯示了「Churn」型別程式碼的變化：
對於2024年的預測，這裏使用OpenAI的gpt-4-1106-preview助手，對現有數據進行二次回歸分析。
透過對比2022年與2023年的操作頻率差異，辨識出了三個可能影響程式碼品質的警示訊號：
危險訊號
2023 年，我們目睹了程式碼攪動、移動和復制貼上方面的顯著變化，這些變化背後的含義值得深入探討。
程式碼攪動的新趨勢
「程式碼攪動（Churn）」反映了推播到程式碼倉庫後，在接下來的兩周內被撤銷、移除或更新的程式碼比例。
過去，當開發者完全自主編寫程式碼時，這種情況相對罕見——2023年之前，僅有3-4%的程式碼會發生攪動。
然而，2022年，隨著Copilot的首次亮相和ChatGPT的問世，程式碼攪動率的預兆性跳升至9%。
2022至2023年間，AI助手的崛起與倉庫中錯誤程式碼的增加密切相關。
假設Copilot在2021年的普及率為0%，2022年為5-10%，2023年達到30%，這些變量之間的Pearson相關系數高達0.98，顯示了它們的同步增長。
隨著程式碼攪動成為常態，錯誤程式碼部署到生產環境的風險也隨之增大。如果這一趨勢持續到2024年，超過7%的程式碼更改可能會在兩周內被撤銷，這是2021年的兩倍。
據此，報告預計Google DORA在年底釋出的「2024 Devops 狀態」報告中，將顯示「變更失敗率」的上升。當然前提是研究包含了2023年使用AI輔助的開發者數據。
程式碼移動減少，反映出重構和復用的減少
程式碼移動通常出現在對現有程式碼系統進行重構時。
重構系統，特別是程式碼的移動，是程式碼復用的基礎。隨著產品範圍擴大，開發者會將現有程式碼重組到新的模組和檔中，以便新功能復用。
對經驗豐富的開發者而言，程式碼復用的好處顯而易見——與新增程式碼相比，復用的程式碼已經過測試並在生產環境中證明其穩定性。
復用的程式碼往往已被多人修改，更可能包含文件，這有助於新人更快理解模組。
隨著標記為「復制貼上」的程式碼增加，AI助手似乎在抑制程式碼的復用，而是提供了一種重復現有程式碼的簡單方式，而不是鼓勵重構和遵循「不要重復自己（DRY）」的原則。
復制貼上程式碼增多，預示著未來的維護困難
長期來看，復制貼上程式碼可能是對程式碼可維護性的影響最大的因素。
當程式碼行被重復使用時，本質上意味著「我沒有時間去評估之前的實作方式」。
選擇復制貼上新程式碼而沒有復用程式碼，會使得未來的維護工作變得更加困難，因為需要整合那些實作相同功能的平行程式碼的實作方式。
大多數開發者更喜歡「實作新功能」而不是「解讀可能可復用的程式碼」，因此復制貼上的程式碼往往會長時間存在。
而且在經驗缺乏的團隊中，可能沒有有能力且有權威的程式碼維護者來刪除那些重復的程式碼。
即便是資深開發者，要充分理解程式碼從而刪除某些重復的程式碼，所需的努力也是非常巨大的。
如果沒有CTO或工程負責人主動安排時間來減輕技術債，那麽「自上而下的時間壓力」就會成為新添加的復制貼上程式碼，讓這些程式碼永遠無法整合到改善長期開發速度的庫中的又一個原因。
由於GitClear只統計單次送出中的重復程式碼，2023年測得的11%復制貼上比例可能只是只是今年復制貼上程式碼非常小的一部份。
總結
根據報告評估的兩個關鍵數據點顯示，2023年程式碼品質出現了嚴重的下降。這種情況與大語言模型（LLM）的廣泛套用，尤其是AI程式碼助手的流行有直接關聯。
GitHub與Wakefield Research在2023年的一項調查反映出開發者已經意識到程式碼品質的下降。
當被問及「在沒有AI輔助的情況下，你認為應該評估哪些指標？」他們最關註的是「協作與溝通」，緊隨其後的是「程式碼品質」。
而當問題變為「在使用AI輔助時，你認為應該評估哪些指標？」他們的答案發生了變化，其中「程式碼品質」躍升為最受關註的問題，「生產環境中的問題事件」也上升至第三位：
單個開發者的情況可能無法說明為何「程式碼品質」和「生產環境中的問題事件」在使用AI時顯得更加重要，但報告的數據揭示了一個可能的原因：
當開發者被一波又一波看似合適、能短期內解決問題的建議所淹沒時，他們很容易不斷增加程式碼量，卻忽視了程式碼的最佳化和復用。
——如果按一下Tab鍵就能解決當前的問題，為什麽要費心思管以後的事情？
AI助手和Copilot將如何重塑開發者的角色？隨著AI技術的廣泛套用，毫無疑問，我們已經進入了一個程式碼增長速度空前的新時代。
那麽，2024年的問題可能是：誰來收拾事後的爛攤子？
網友討論
面對AI帶來的「全球程式碼品質下行」，網友也是深有體會：
譴責型：「我在兩個月後取消了訂閱（Copilot），因為我花了太多精力去修復所有程式碼錯誤。而且在處理任何復雜的事情或與SQL有關的事情時，它基本上是無用的(即使我提前載入了整個模式)。」
大佬型：「寫下所有東西其實要花的功夫少得多，因為我知道自己想寫什麽，而且修正自己的錯誤比修正機器人的錯誤更容易」。
悲天憫人型：「我為那些將被這種垃圾徹底擊垮的初學者而哭泣。」
中立型：「Copilot能做的事讓我很吃驚，但確實不能說生成的程式碼很好。生成的程式碼肯定得改，但是確實能幫你省不少時間」。
參考資料：https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality
