狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

LOGO OA教程 ERP教程 模切知識(shí)交流 PMS教程 CRM教程 開(kāi)發(fā)文檔 其他文檔  
 
網(wǎng)站管理員

[點(diǎn)晴永久免費(fèi)OA]AI正在使全球代碼質(zhì)量下降!1.53億行代碼深度分析報(bào)告出爐

freeflydom
2024年1月31日 19:7 本文熱度 1203

  想不到,AI 生成的內(nèi)容影響數(shù)據(jù)質(zhì)量的問(wèn)題,已經(jīng)在代碼上出現(xiàn)了。最近,GitClear 發(fā)布的一項(xiàng)調(diào)查報(bào)告顯示,用 AI 寫代碼,正在導(dǎo)致「全球代碼質(zhì)量面臨下行趨勢(shì)」。

  這引起了全網(wǎng)熱烈討論:

  「借助 AI 提供商,您可以將代碼生成速度提高 50%(即使是您不理解或無(wú)法編寫的代碼),但代價(jià)是代碼的質(zhì)量和可持續(xù)性不斷下降。」

  「我們要追求的,到底是質(zhì)量還是速度?」

  調(diào)查中,GitClear 分析了從 2020 年 1 月到 2023 年 12 月之間編寫的 1.53 億行代碼更改數(shù)據(jù),

  ——1.53 億行代碼,是目前已知最大的用于評(píng)估代碼質(zhì)量差異的數(shù)據(jù)集。

  調(diào)查發(fā)現(xiàn)了什么?我們先看下面這張圖:

  圖中展示了 4 年中的代碼改動(dòng)率——編寫后不到兩周就被撤銷或更新的代碼行百分比,——深色部分表示受 AI 代碼生成工具影響的時(shí)間。

  調(diào)查中同樣發(fā)現(xiàn),「新增代碼」和「復(fù)制粘貼代碼」的比例相對(duì)于「更新」、「刪除」和「移動(dòng)」代碼的比例在增加。

  這貌似說(shuō)明開(kāi)發(fā)人員在大量使用 Copilot 等 AI 代碼生成工具,快速生成了大量代碼,但隨后發(fā)現(xiàn)了代碼中的問(wèn)題,——GitClear 的報(bào)告預(yù)計(jì)在 2024 年,這個(gè)代碼改動(dòng)率將達(dá)到 2021 年 AI 出現(xiàn)前的兩倍。

  另外一點(diǎn)就是,AI 代碼生成工具不太理會(huì)人類程序員的一些原則(比如「重復(fù)造輪子」這件事),也就造成了代碼庫(kù)中越來(lái)越多的重復(fù)代碼。

  ——不過(guò)很多碼農(nóng)都是「CV 程序員」,這樣看來(lái),AI 也算是學(xué)到了精髓。

  2023 年,GitHub Copilot 大放異彩。在短短不到兩年時(shí)間內(nèi),這款 AI 編程助手從一個(gè)「原型」迅速成長(zhǎng)為「核心工具」,被全球數(shù)百萬(wàn)開(kāi)發(fā)者在數(shù)十萬(wàn)家企業(yè)中廣泛應(yīng)用,開(kāi)啟了 coding 的新時(shí)代。

  對(duì)此,GitHub 發(fā)表了多篇研究論文,探討了 AI 在軟件開(kāi)發(fā)領(lǐng)域的增長(zhǎng)與影響。

  速度提升 55%,GDP 增加 1.5 萬(wàn)億

  研究表明,使用 Copilot 的開(kāi)發(fā)者編碼速度可以提高「55%」,導(dǎo)致總的代碼量增加了 46%,并且為全球創(chuàng)造了 1.5 萬(wàn)億美元 GDP。

  有了這樣的成績(jī),也就不難理解為什么 GitHub 的 CEO Thomas Dohmke,會(huì)在繁忙的工作之余,專門撰寫關(guān)于 AI 革命的文章。

  在 2023 年 2 月 Copilot 個(gè)人版用戶超過(guò)一百萬(wàn)之后,GitHub 又推出了 GitHub Copilot for Business 版本。

  那么,有多少開(kāi)發(fā)者在用 AI 來(lái)編寫代碼呢?

  GitHub 與 Wakefield Research 在 2023 年 6 月的一項(xiàng)研究中指出,92% 的美國(guó)大型公司的開(kāi)發(fā)者表示他們使用了 AI 編程工具。并且有 70% 的開(kāi)發(fā)者認(rèn)為使用 AI 帶來(lái)了明顯的好處。

  不過(guò),O’Reilly Publishing 在 2023 年 8 月給出的調(diào)查數(shù)據(jù)顯示,67% 的開(kāi)發(fā)者沒(méi)有用過(guò) ChatGPT 或 Copilot。不管怎樣,GitHub 在市場(chǎng)上仍有巨大的潛力等待挖掘。

  ——然而,大語(yǔ)言模型(LLM)生成的代碼引發(fā)的一個(gè)問(wèn)題是:

  這些代碼的質(zhì)量和可維護(hù)性到底怎么樣?

  面對(duì) AI 滔滔不絕吐出的一大堆代碼,程序員似乎不太容易發(fā)現(xiàn)其中的問(wèn)題——畢竟都不是自己寫的。

  還有,眾所周知,當(dāng)程序員接手前人留下來(lái)的*山代碼時(shí),應(yīng)該遵守的「潛規(guī)則」是:

  如果這個(gè)代碼能夠正常運(yùn)行,就千萬(wàn)不要妄想去重構(gòu)。

  AI 生成代碼背后的挑戰(zhàn)

  無(wú)法否認(rèn),Copilot 實(shí)實(shí)在在的提升了開(kāi)發(fā)者的編碼效率。GitHub 的研究顯示,使用 Copilot 的開(kāi)發(fā)者滿意度提升了 75%。

  做初期產(chǎn)品開(kāi)發(fā)的人是滿意了,可后面負(fù)責(zé)長(zhǎng)期維護(hù)的人就蛋疼了。

  資深代碼研究者 Adam Tornhill(著有《代碼即犯罪現(xiàn)場(chǎng)》)對(duì)此持保留態(tài)度:

  使用 Copilot 可以使代碼編寫速度提高 55%,但如果是本就不應(yīng)該編寫的代碼呢?

  如《Clean Code: A Handbook of Agile Software Craftsmanship》一書的作者 Robert Martin 所說(shuō),代碼的閱讀時(shí)間是編寫時(shí)間的十倍。快速編寫糟糕的代碼,意味著給后來(lái)的代碼閱讀者帶來(lái)了巨大的負(fù)擔(dān)。

  此外,AI 代碼助手還帶來(lái)了其他問(wèn)題:

  比如代碼助手擅長(zhǎng)生成代碼,卻不擅長(zhǎng)修改;當(dāng)有多個(gè)生成工具給出建議時(shí),評(píng)估哪個(gè)更好是很耗費(fèi)時(shí)間的;

  最后,AI 代碼助手與開(kāi)發(fā)者的動(dòng)機(jī)可能不同,對(duì)于代碼優(yōu)化來(lái)說(shuō),AI 往往傾向于提出最有可能被接受的建議。

  所以,相比于經(jīng)驗(yàn)更豐富的開(kāi)發(fā)人員,初級(jí)開(kāi)發(fā)者更傾向于接受 AI 給出的代碼建議:

  而老鳥們深知,隨著時(shí)間推移,代碼的維護(hù)成本會(huì)越來(lái)越高。

  代碼操作介紹

  GitClear 將代碼變更分為七個(gè)類別(研究中涉及前六種):

1. 新增代碼:首次提交的代碼行,代碼行是全新的,不包括對(duì)現(xiàn)有代碼行的小幅修改,也不包括那些被添加、移除后又重新添加的代碼行。 2. 刪除代碼:被刪除并提交的代碼行,且至少在隨后的兩周內(nèi)未被重新加入。 3. 移動(dòng)代碼:將一行代碼剪切并粘貼到新文件或同一文件內(nèi)的新函數(shù)中?!敢苿?dòng)」的操作僅涉及位置的變換,代碼內(nèi)容不發(fā)生改變。 4. 更新代碼:修改大約三個(gè)或更少的單詞來(lái)更改原有代碼行。 5. 查找/替換代碼:從三個(gè)或更多位置移除相同字符串,并用一致的內(nèi)容進(jìn)行替換。 6. 復(fù)制/粘貼代碼:在一次提交中,將相同的代碼行內(nèi)容復(fù)制到多個(gè)文件或函數(shù)中。 7. 無(wú)操作代碼:指一些微小的代碼變更,比如空格或同一代碼塊內(nèi)行號(hào)的變化。

  GitClear 自 2020 年起根據(jù)這些操作對(duì) git 倉(cāng)庫(kù)進(jìn)行分類,并在 Diff Delta 文檔中提供了代碼操作的具體示例。

  截至 2024 年 1 月,GitClear 分析并分類了大約十億行代碼,這些代碼來(lái)自商業(yè)客戶(如 NextGen Health, Verizon)和流行的開(kāi)源倉(cāng)庫(kù)(如 Facebook React, Google Chrome)。

  其中,1.53 億行代碼為有意義的變更,被用于本研究。

  最后,還有一個(gè)單獨(dú)的定義叫做「攪動(dòng)」(churn),意思是代碼被創(chuàng)建、推送到 git 倉(cāng)庫(kù)后,在接下來(lái)的兩周內(nèi)被撤銷或大幅修改。

  ——也就是咱們最開(kāi)始分析的那張圖,可以將「攪動(dòng)」理解為,作者一開(kāi)始編寫、提交并推送到公司 git 倉(cāng)庫(kù)的代碼有問(wèn)題,后來(lái)發(fā)現(xiàn)了。

  數(shù)據(jù)分析

  下表根據(jù) GitClear 的數(shù)據(jù),分析了不同的代碼行操作數(shù)量,并按照代碼的編寫年份進(jìn)行分類。

  表中的前六項(xiàng)就是上面提到的代碼變更的前六個(gè)類別,而最后一項(xiàng)是「攪動(dòng)」。

  將表格數(shù)據(jù)繪制成下面的圖表,可以更清晰地看出各種代碼操作類型的變化趨勢(shì),比如,圖表中的淺藍(lán)色細(xì)線顯示了「Churn」類型代碼的變化:

  對(duì)于 2024 年的預(yù)測(cè),這里使用 OpenAI 的 gpt-4-1106-preview 助手,對(duì)現(xiàn)有數(shù)據(jù)進(jìn)行二次回歸分析。

  通過(guò)對(duì)比 2022 年與 2023 年的操作頻率差異,識(shí)別出了三個(gè)可能影響代碼質(zhì)量的警示信號(hào):

  危險(xiǎn)信號(hào)

  2023 年,我們目睹了代碼攪動(dòng)、移動(dòng)和復(fù)制粘貼方面的顯著變化,這些變化背后的含義值得深入探討。

  代碼攪動(dòng)的新趨勢(shì)

  「代碼攪動(dòng)(Churn)」反映了推送到代碼倉(cāng)庫(kù)后,在接下來(lái)的兩周內(nèi)被撤銷、移除或更新的代碼比例。

  過(guò)去,當(dāng)開(kāi)發(fā)者完全自主編寫代碼時(shí),這種情況相對(duì)罕見(jiàn)——2023 年之前,僅有3-4% 的代碼會(huì)發(fā)生攪動(dòng)。

  然而,2022 年,隨著 Copilot 的首次亮相和 ChatGPT 的問(wèn)世,代碼攪動(dòng)率的預(yù)兆性跳升至9%。

  2022 至 2023 年間,AI 助手的崛起與倉(cāng)庫(kù)中錯(cuò)誤代碼的增加密切相關(guān)。

  假設(shè) Copilot 在 2021 年的普及率為0%,2022 年為5-10%,2023 年達(dá)到 30%,這些變量之間的 Pearson 相關(guān)系數(shù)高達(dá) 0.98,顯示了它們的同步增長(zhǎng)。

  隨著代碼攪動(dòng)成為常態(tài),錯(cuò)誤代碼部署到生產(chǎn)環(huán)境的風(fēng)險(xiǎn)也隨之增大。如果這一趨勢(shì)持續(xù)到 2024 年,超過(guò)7% 的代碼更改可能會(huì)在兩周內(nèi)被撤銷,這是 2021 年的兩倍。

  據(jù)此,報(bào)告預(yù)計(jì) Google DORA 在年底發(fā)布的「2024 Devops 狀態(tài)」報(bào)告中,將顯示「變更失敗率」的上升。當(dāng)然前提是研究包含了 2023 年使用 AI 輔助的開(kāi)發(fā)者數(shù)據(jù)。

  代碼移動(dòng)減少,反映出重構(gòu)和復(fù)用的減少

  代碼移動(dòng)通常出現(xiàn)在對(duì)現(xiàn)有代碼系統(tǒng)進(jìn)行重構(gòu)時(shí)。

  重構(gòu)系統(tǒng),特別是代碼的移動(dòng),是代碼復(fù)用的基礎(chǔ)。隨著產(chǎn)品范圍擴(kuò)大,開(kāi)發(fā)者會(huì)將現(xiàn)有代碼重組到新的模塊和文件中,以便新功能復(fù)用。

  對(duì)經(jīng)驗(yàn)豐富的開(kāi)發(fā)者而言,代碼復(fù)用的好處顯而易見(jiàn)——與新增代碼相比,復(fù)用的代碼已經(jīng)過(guò)測(cè)試并在生產(chǎn)環(huán)境中證明其穩(wěn)定性。

  復(fù)用的代碼往往已被多人修改,更可能包含文檔,這有助于新人更快理解模塊。

  隨著標(biāo)記為「復(fù)制粘貼」的代碼增加,AI 助手似乎在抑制代碼的復(fù)用,而是提供了一種重復(fù)現(xiàn)有代碼的簡(jiǎn)單方式,而不是鼓勵(lì)重構(gòu)和遵循「不要重復(fù)自己(DRY)」的原則。

  復(fù)制粘貼代碼增多,預(yù)示著未來(lái)的維護(hù)困難

  長(zhǎng)期來(lái)看,復(fù)制粘貼代碼可能是對(duì)代碼可維護(hù)性的影響最大的因素。

  當(dāng)代碼行被重復(fù)使用時(shí),本質(zhì)上意味著「我沒(méi)有時(shí)間去評(píng)估之前的實(shí)現(xiàn)方式」。

  選擇復(fù)制粘貼新代碼而沒(méi)有復(fù)用代碼,會(huì)使得未來(lái)的維護(hù)工作變得更加困難,因?yàn)樾枰夏切?shí)現(xiàn)相同功能的平行代碼的實(shí)現(xiàn)方式。

  大多數(shù)開(kāi)發(fā)者更喜歡「實(shí)現(xiàn)新功能」而不是「解讀可能可復(fù)用的代碼」,因此復(fù)制粘貼的代碼往往會(huì)長(zhǎng)時(shí)間存在。

  而且在經(jīng)驗(yàn)缺乏的團(tuán)隊(duì)中,可能沒(méi)有有能力且有權(quán)威的代碼維護(hù)者來(lái)刪除那些重復(fù)的代碼。

  即便是資深開(kāi)發(fā)者,要充分理解代碼從而刪除某些重復(fù)的代碼,所需的努力也是非常巨大的。

  如果沒(méi)有 CTO 或工程負(fù)責(zé)人主動(dòng)安排時(shí)間來(lái)減輕技術(shù)債,那么「自上而下的時(shí)間壓力」就會(huì)成為新添加的復(fù)制粘貼代碼,讓這些代碼永遠(yuǎn)無(wú)法整合到改善長(zhǎng)期開(kāi)發(fā)速度的庫(kù)中的又一個(gè)原因。

  由于 GitClear 只統(tǒng)計(jì)單次提交中的重復(fù)代碼,2023 年測(cè)得的 11% 復(fù)制粘貼比例可能只是只是今年復(fù)制粘貼代碼非常小的一部分。

  總結(jié)

  根據(jù)報(bào)告評(píng)估的兩個(gè)關(guān)鍵數(shù)據(jù)點(diǎn)顯示,2023 年代碼質(zhì)量出現(xiàn)了嚴(yán)重的下降。這種情況與大語(yǔ)言模型(LLM)的廣泛應(yīng)用,尤其是 AI 代碼助手的流行有直接關(guān)聯(lián)。

  GitHub 與 Wakefield Research 在 2023 年的一項(xiàng)調(diào)查反映出開(kāi)發(fā)者已經(jīng)意識(shí)到代碼質(zhì)量的下降。

  當(dāng)被問(wèn)及「在沒(méi)有 AI 輔助的情況下,你認(rèn)為應(yīng)該評(píng)估哪些指標(biāo)?」他們最關(guān)注的是「協(xié)作與溝通」,緊隨其后的是「代碼質(zhì)量」。

  而當(dāng)問(wèn)題變?yōu)椤冈谑褂?AI 輔助時(shí),你認(rèn)為應(yīng)該評(píng)估哪些指標(biāo)?」他們的答案發(fā)生了變化,其中「代碼質(zhì)量」躍升為最受關(guān)注的問(wèn)題,「生產(chǎn)環(huán)境中的問(wèn)題事件」也上升至第三位:

  單個(gè)開(kāi)發(fā)者的情況可能無(wú)法說(shuō)明為何「代碼質(zhì)量」和「生產(chǎn)環(huán)境中的問(wèn)題事件」在使用 AI 時(shí)顯得更加重要,但報(bào)告的數(shù)據(jù)揭示了一個(gè)可能的原因:

  當(dāng)開(kāi)發(fā)者被一波又一波看似合適、能短期內(nèi)解決問(wèn)題的建議所淹沒(méi)時(shí),他們很容易不斷增加代碼量,卻忽視了代碼的優(yōu)化和復(fù)用。

  ——如果按一下 Tab 鍵就能解決當(dāng)前的問(wèn)題,為什么要費(fèi)心思管以后的事情?

  AI 助手和 Copilot 將如何重塑開(kāi)發(fā)者的角色?隨著 AI 技術(shù)的廣泛應(yīng)用,毫無(wú)疑問(wèn),我們已經(jīng)進(jìn)入了一個(gè)代碼增長(zhǎng)速度空前的新時(shí)代。

  那么,2024 年的問(wèn)題可能是:誰(shuí)來(lái)收拾事后的爛攤子?

  網(wǎng)友討論

  面對(duì) AI 帶來(lái)的「全球代碼質(zhì)量下行」,網(wǎng)友也是深有體會(huì):

  譴責(zé)型:「我在兩個(gè)月后取消了訂閱(Copilot),因?yàn)槲一颂嗑θバ迯?fù)所有代碼錯(cuò)誤。而且在處理任何復(fù)雜的事情或與 SQL 有關(guān)的事情時(shí),它基本上是無(wú)用的(即使我提前加載了整個(gè)模式)?!?/p>

  大佬型:「寫下所有東西其實(shí)要花的功夫少得多,因?yàn)槲抑雷约合雽懯裁?,而且修正自己的錯(cuò)誤比修正機(jī)器人的錯(cuò)誤更容易」。

  悲天憫人型:「我為那些將被這種垃圾徹底擊垮的初學(xué)者而哭泣?!?/p>

  中立型:「Copilot 能做的事讓我很吃驚,但確實(shí)不能說(shuō)生成的代碼很好。生成的代碼肯定得改,但是確實(shí)能幫你省不少時(shí)間」。

  參考資料:


轉(zhuǎn)自公眾號(hào)新智元


該文章在 2024/2/2 8:54:30 編輯過(guò)
關(guān)鍵字查詢
相關(guān)文章
正在查詢...
點(diǎn)晴ERP是一款針對(duì)中小制造業(yè)的專業(yè)生產(chǎn)管理軟件系統(tǒng),系統(tǒng)成熟度和易用性得到了國(guó)內(nèi)大量中小企業(yè)的青睞。
點(diǎn)晴PMS碼頭管理系統(tǒng)主要針對(duì)港口碼頭集裝箱與散貨日常運(yùn)作、調(diào)度、堆場(chǎng)、車隊(duì)、財(cái)務(wù)費(fèi)用、相關(guān)報(bào)表等業(yè)務(wù)管理,結(jié)合碼頭的業(yè)務(wù)特點(diǎn),圍繞調(diào)度、堆場(chǎng)作業(yè)而開(kāi)發(fā)的。集技術(shù)的先進(jìn)性、管理的有效性于一體,是物流碼頭及其他港口類企業(yè)的高效ERP管理信息系統(tǒng)。
點(diǎn)晴WMS倉(cāng)儲(chǔ)管理系統(tǒng)提供了貨物產(chǎn)品管理,銷售管理,采購(gòu)管理,倉(cāng)儲(chǔ)管理,倉(cāng)庫(kù)管理,保質(zhì)期管理,貨位管理,庫(kù)位管理,生產(chǎn)管理,WMS管理系統(tǒng),標(biāo)簽打印,條形碼,二維碼管理,批號(hào)管理軟件。
點(diǎn)晴免費(fèi)OA是一款軟件和通用服務(wù)都免費(fèi),不限功能、不限時(shí)間、不限用戶的免費(fèi)OA協(xié)同辦公管理系統(tǒng)。
Copyright 2010-2025 ClickSun All Rights Reserved