分析了1.5億行代碼發(fā)現(xiàn):AI編程助手降低代碼質(zhì)量
點(diǎn)擊關(guān)注公眾號(hào)，Java干貨 及時(shí)送達(dá)
摘要
2023 年是 GitHub Copilot 大放異彩的一年。在短短不到兩年的時(shí)間里，這款 AI 編程助手已從一個(gè)初步的原型迅速成為眾多開(kāi)發(fā)者和企業(yè)中不可或缺的重要工具 [1]。它的迅猛發(fā)展開(kāi)啟了編寫(xiě)代碼的新紀(jì)元。 GitHub 已經(jīng)發(fā)布了數(shù)份關(guān)于 AI 如何影響軟件開(kāi)發(fā)的增長(zhǎng)和影響的研究。他們的一項(xiàng)重要發(fā)現(xiàn)是，開(kāi)發(fā)者在使用 Copilot 時(shí)，編碼速度提升了 “55%”。面對(duì)大量由 LLM 生成的代碼，我們不禁要問(wèn)：這些代碼在質(zhì)量和可維護(hù)性上與人工編寫(xiě)的代碼相比如何？它們是不是更像經(jīng)驗(yàn)豐富的高級(jí)開(kāi)發(fā)者的精心作品，還是更接近短期合同工的零散拼湊？ 為此，GitClear 收集了從 2020 年 1 月到 2023 年 12 月之間的 153 百萬(wàn)行代碼變更記錄 [A1]。這是目前已知最大的用于分析代碼質(zhì)量差異的高度結(jié)構(gòu)化代碼變更數(shù)據(jù)集 [A2]。 我們發(fā)現(xiàn)了一些關(guān)于代碼可維護(hù)性的令人擔(dān)憂(yōu)的趨勢(shì)。代碼變更率 —— 指在編寫(xiě)后不到兩周就被修改或撤銷(xiāo)的代碼行所占的比例 —— 預(yù)計(jì)在 2024 年將是 2021 年 AI 出現(xiàn)之前的兩倍。我們還發(fā)現(xiàn)，“新增代碼” 和 “復(fù)制 / 粘貼代碼” 的比例相比于 “更新的”、“刪除的” 和 “移動(dòng)的” 代碼在上升。從這個(gè)角度來(lái)看，AI 生成的代碼更像是一位頻繁更換工作的合同工寫(xiě)的臨時(shí)代碼，容易違反他訪(fǎng)問(wèn)的代碼庫(kù)的 DRY（Donot Repeat Yourself，不重復(fù)自己）原則。。 我們以一些針對(duì)管理者如何在這種逆流中保持代碼高質(zhì)量的建議作為本文的總結(jié)。
GitHub: “使用 AI 編程，提升效率 55%，增加代碼量 46%，為 GDP 貢獻(xiàn) 1.5 萬(wàn)億美元”
這樣驚人的數(shù)據(jù)背后，GitHub 的 CEO Thomas Dohmke 不僅忙于日常的 CEO 工作，還專(zhuān)門(mén)抽時(shí)間撰寫(xiě)了關(guān)于 AI 革命的博客文章和研究論文。他在 2023 年發(fā)布于 GitHub 的作品，詳細(xì)敘述了 Copilot 快速普及的激動(dòng)人心的故事。
來(lái)自 Dohmke 2023 年的博客文章《AI 驅(qū)動(dòng)開(kāi)發(fā)者生命周期的經(jīng)濟(jì)影響及從 GitHub Copilot 學(xué)到的經(jīng)驗(yàn)》 Dohmke 在博客中提出，目前已有超過(guò) 20,000 家組織在使用 GitHub Copilot for Business。這緊隨其在 2023 年 2 月宣布的消息，即在 Copilot for Business 推出時(shí)，“已有超過(guò)一百萬(wàn)人” 在使用個(gè)人版 Copilot。GitHub 在提高 AI 質(zhì)量和公開(kāi)透明地分享其成果方面取得了令人贊賞的進(jìn)展。 到底有多少開(kāi)發(fā)者正在使用 AI 編寫(xiě)代碼？在 GitHub 2023 年 6 月與 Wakefield Research 合作的一項(xiàng)獨(dú)立研究中，他們指出：“在美國(guó)大型公司工作的開(kāi)發(fā)者中，有 92% 使用 AI 編程工具。” 他們還強(qiáng)調(diào)，有 70% 的開(kāi)發(fā)者認(rèn)為使用 AI 帶來(lái)了顯著好處。不過(guò)，O’Reilly Publishing 在 2023 年 8 月的一項(xiàng)調(diào)查顯示，67% 的受訪(fǎng)開(kāi)發(fā)者表示他們還沒(méi)有使用 ChatGPT 或 Copilot。這暗示了 GitHub 在市場(chǎng)上仍有很大的增長(zhǎng)潛力。
AI 生成代碼存在的問(wèn)題
開(kāi)發(fā)者之所以采用 Copilot，是因?yàn)樗麄兿嘈胚@款工具能夠加快編碼速度。GitHub 的研究發(fā)現(xiàn)，使用 Copilot 的開(kāi)發(fā)者的滿(mǎn)意度提高了 75%。這表明開(kāi)發(fā)者普遍接受了這款產(chǎn)品。但是，這并不意味著那些負(fù)責(zé)維護(hù)代碼的人也會(huì)感到同樣滿(mǎn)意。資深代碼研究員 Adam Tornhill（著有《Your Code as a Crime Scene》）對(duì)此表示懷疑：
開(kāi)發(fā)者研究人員對(duì) AI 輔助編程的影響持擔(dān)憂(yōu)態(tài)度 GitHub 聲稱(chēng)，使用 Copilot 編寫(xiě)代碼的速度提高了 55%。但問(wèn)題是，有些本不應(yīng)編寫(xiě)的代碼怎么辦？正如《Clean Code: A Handbook of Agile Software Craftsmanship》的作者 Robert Martin 所說(shuō)，代碼的閱讀時(shí)間是編寫(xiě)時(shí)間的十倍。更快地寫(xiě)出低質(zhì)量代碼，意味著后續(xù)閱讀代碼的人將面臨更多困難。 這只是使用 AI 助手的開(kāi)發(fā)者所面臨的眾多挑戰(zhàn)之一。其他挑戰(zhàn)包括：
-
頻繁收到增加代碼的建議，卻很少有關(guān)于更新、移動(dòng)或刪除代碼的建議。這是源于文本環(huán)境中代碼編寫(xiě)時(shí)的界面限制。
-
評(píng)估代碼建議可能耗費(fèi)大量時(shí)間，尤其是在有多個(gè)自動(dòng)建議系統(tǒng)相互競(jìng)爭(zhēng)的環(huán)境中，如流行的 JetBrains IDEs（參見(jiàn) [11]）。
-
代碼建議的優(yōu)化并非基于和代碼維護(hù)者相同的激勵(lì)機(jī)制。代碼建議算法旨在提出最可能被接受的建議，而代碼維護(hù)者則努力減少需要閱讀的代碼量（即，理解如何調(diào)整現(xiàn)有系統(tǒng)）。
GitHub 的數(shù)據(jù)顯示，相比經(jīng)驗(yàn)豐富的開(kāi)發(fā)者，初級(jí)開(kāi)發(fā)者使用 Copilot 的頻率高出大約 20% 經(jīng)驗(yàn)豐富的開(kāi)發(fā)者更深刻地理解維護(hù)代碼的長(zhǎng)期成本。如果他們更不愿使用 AI 的代碼建議，那么這是否意味著初級(jí)開(kāi)發(fā)者現(xiàn)在正以前所未有的速度貢獻(xiàn)更多額外的代碼呢？
代碼變更的分類(lèi)
為了探究代碼質(zhì)量如何隨著時(shí)間變化，我們研究了在 AI 應(yīng)用日益廣泛的 2023 年與之前幾年，代碼變更類(lèi)型的不同。GitClear 將代碼的變更動(dòng)作分為七大類(lèi)別，本研究分析了其中的六種：-
新增代碼。指新增加的獨(dú)立代碼行，不包含對(duì)現(xiàn)有代碼的小幅修改（這類(lèi)修改被標(biāo)記為 “更新”）。此外，新增代碼也不包括那些被添加、刪除后又重新加入的代碼行（這些行被標(biāo)記為 “更新” 和 “變動(dòng)”）。
-
刪除代碼。指被移除、提交并且在隨后的至少兩周內(nèi)沒(méi)有被重新加入的代碼行。
-
移動(dòng)代碼。指被剪切并粘貼到新文件或同一文件中新的函數(shù)位置的代碼行。按照定義，“移動(dòng)” 的操作中，提交時(shí)代碼內(nèi)容不變，除了代碼前的空格部分可能會(huì)有所改變。
-
更新代碼。基于已存在的代碼行，通過(guò)修改大約三個(gè)詞或更少的詞匯來(lái)提交的新代碼行。
-
查找 / 替換代碼。這種變更模式中，同一字符串在三個(gè)或更多位置被替換為統(tǒng)一的新內(nèi)容。
-
復(fù)制 / 粘貼代碼。除了編程語(yǔ)言的關(guān)鍵字（例如，
end，}，[）外，相同的代碼內(nèi)容被提交到一個(gè)提交中的多個(gè)文件或函數(shù)。 -
無(wú)效操作代碼。微小的代碼更改，如空格或同一代碼塊內(nèi)的行號(hào)變更。這類(lèi)無(wú)效操作的代碼變更沒(méi)有包含在本研究中。
Copilot 對(duì)代碼編輯操作趨勢(shì)的影響
為了深入了解 Copilot 如何影響代碼質(zhì)量，我們對(duì) GitClear 觀察到的各種代碼行操作進(jìn)行了分析，這些操作按照代碼編寫(xiě)的年份來(lái)分類(lèi)（依據(jù) git 提交記錄中的 authored_at 日期 [12]）。相關(guān)的詳細(xì)數(shù)據(jù)可以在附錄中找到。下面是各年份的操作百分比：| 新增 | 刪除 | 更新 | 移動(dòng) | 復(fù)制 / 粘貼 | 查找 / 替換 | 代碼波動(dòng) | |
|---|---|---|---|---|---|---|---|
| 2020 | 39.2% | 19.5% | 5.2% | 25.0% | 8.3% | 2.9% | 3.3% |
| 2021 | 39.5% | 19.0% | 5.0% | 24.8% | 8.4% | 3.4% | 3.6% |
| 2022 | 41.0% | 20.2% | 5.2% | 20.5% | 9.4% | 3.7% | 4.0% |
| 2023 | 42.3% | 21.1% | 5.5% | 16.9% | 10.5% | 3.6% | 5.5% |
| 2024 | 43.6% | 22.1% | 5.8% | 13.4% | 11.6% | 3.6% | 7.1% |
對(duì)于 2024 年的預(yù)測(cè)，我們利用 OpenAI 的 gpt-4-1106-preview 模型，通過(guò)對(duì)現(xiàn)有數(shù)據(jù)進(jìn)行二次回歸分析得出。附錄中詳細(xì)介紹了我們?nèi)绾问褂?OpenAI 模型進(jìn)行這一分析。鑒于 GitHub 報(bào)告的 Copilot 的迅猛發(fā)展以及 AI 智能體的普遍應(yīng)用，可以預(yù)見(jiàn) 2024 年的趨勢(shì)將延續(xù) 2022 年開(kāi)始顯現(xiàn)的模式，并在 2023 年得到加速。單從 2022 年到 2023 年各種操作頻率的變化來(lái)看，我們可以發(fā)現(xiàn)三個(gè)可能影響代碼質(zhì)量的警示信號(hào)：
| 操作 | 同比變化 |
|---|---|
| 添加 | +3.1% |
| 刪除 | +4.8% |
| 更新 | +5.2% |
| 移動(dòng) | -17.3% |
| 復(fù)制 / 粘貼 | +11.3% |
| 查找 / 替換 | -1.3% |
| 代碼變動(dòng)率 (Churn) | +39.2% |
解讀代碼操作變化的含義
2023 年最顯著的代碼操作變化發(fā)生在 “代碼變動(dòng)率 (Churn)”、“移動(dòng)” 和 “復(fù)制 / 粘貼” 這幾個(gè)方面。我們?cè)谶@一節(jié)將詳細(xì)探討這些變化背后的意義。代碼變動(dòng)率的顯著增長(zhǎng)
所謂的 “代碼變動(dòng)率 (Churn)” 是指代碼被推送到倉(cāng)庫(kù)后，接著在兩周內(nèi)被撤銷(xiāo)、移除或更新的比例。在開(kāi)發(fā)者親自編寫(xiě)所有代碼的情況下，這種情況相對(duì)較少見(jiàn) ——2023 年之前，只有 3-4% 的代碼會(huì)發(fā)生這樣的變動(dòng)。不過(guò)，在 2022 年就已經(jīng)出現(xiàn)了這種趨勢(shì)的上升，當(dāng)時(shí)代碼變動(dòng)率躍升至 9%。值得注意的是，2022 年是人工智能編程助手 Copilot 首次以測(cè)試版形式推出，同時(shí)也是 ChatGPT 開(kāi)始被廣泛使用的一年。 在 2022 至 2023 年期間，AI 輔助工具的興起與推送到代碼倉(cāng)庫(kù)的 “錯(cuò)誤代碼” 密切相關(guān)。根據(jù)引用資料 [1] 和 [8]，如果我們假設(shè) Copilot 在 2021 年的普及率為 0%，2022 年為 5-10%，2023 年為 30%，那么這些因素之間的相關(guān)性極高，皮爾森相關(guān)系數(shù)高達(dá) 0.98（更多關(guān)于這一計(jì)算的細(xì)節(jié)，請(qǐng)參見(jiàn)附錄中的 “代碼變動(dòng)率與 Copilot 的相關(guān)性” 部分）。這意味著，隨著 AI 輔助工具的使用增加，代碼變動(dòng)率也在相應(yīng)增長(zhǎng)。 隨著代碼變動(dòng)率的普遍增加，錯(cuò)誤代碼被部署到生產(chǎn)環(huán)境的風(fēng)險(xiǎn)也隨之增大。如果這一趨勢(shì)持續(xù)到 2024 年，那么超過(guò) 7% 的代碼更改可能會(huì)在兩周內(nèi)被撤銷(xiāo)，這將是 2021 年的兩倍。根據(jù)這些數(shù)據(jù)，我們預(yù)計(jì) Google DORA 的 “變更失敗率” 將在今年晚些時(shí)候發(fā)布的 “2024 年 DevOps 狀態(tài)報(bào)告” 中有所增加，前提是該研究包含了 2023 年使用 AI 輔助的開(kāi)發(fā)者數(shù)據(jù)。代碼移動(dòng)越少意味著重構(gòu)和復(fù)用的減少
通常在重構(gòu)現(xiàn)有代碼系統(tǒng)時(shí)，我們會(huì)發(fā)現(xiàn)代碼的移動(dòng)。重構(gòu)的系統(tǒng)，尤其是代碼的移動(dòng)，是實(shí)現(xiàn)代碼復(fù)用的關(guān)鍵。隨著產(chǎn)品的不斷擴(kuò)展，開(kāi)發(fā)者往往需要將現(xiàn)有代碼重組到新的模塊和文件中，以便于新功能的復(fù)用。對(duì)于經(jīng)驗(yàn)豐富的開(kāi)發(fā)者來(lái)說(shuō)，代碼復(fù)用的優(yōu)勢(shì)非常明顯 —— 與新編寫(xiě)的代碼相比，已經(jīng)在實(shí)際環(huán)境中被測(cè)試并證實(shí)穩(wěn)定的代碼顯得更加可靠。而且，經(jīng)過(guò)多人修改的代碼往往包含了豐富的文檔，這大大加快了新手開(kāi)發(fā)者對(duì)模塊的理解速度。 結(jié)合 “復(fù)制 / 粘貼” 代碼的增加，可以清楚地看到，當(dāng)前的 AI 助手似乎在一定程度上阻礙了代碼的復(fù)用。相較于進(jìn)行重構(gòu)和遵循 DRY（“不要重復(fù)自己”）原則，這些助手更傾向于提供一種快捷方式，讓開(kāi)發(fā)者重復(fù)使用現(xiàn)有代碼。復(fù)制 / 粘貼的代碼會(huì)導(dǎo)致未來(lái)的維護(hù)困難
復(fù)制 / 粘貼的代碼可能是長(zhǎng)期維護(hù)代碼中最大的難題之一。當(dāng)開(kāi)發(fā)者重復(fù)使用非關(guān)鍵字的代碼行時(shí)，實(shí)際上是在暗示他們沒(méi)有時(shí)間去深入研究之前的實(shí)現(xiàn)方式。這種重復(fù)添加代碼的做法，將整合實(shí)現(xiàn)重復(fù)功能的任務(wù)留給了未來(lái)的維護(hù)者。 大多數(shù)開(kāi)發(fā)者更喜歡 “實(shí)現(xiàn)新功能” 而不是 “審視潛在可復(fù)用的代碼”，因此復(fù)制 / 粘貼的代碼往往會(huì)過(guò)期仍然被使用。尤其在經(jīng)驗(yàn)不足的團(tuán)隊(duì)中，可能缺乏有權(quán)威的代碼維護(hù)者來(lái)移除這些重復(fù)的代碼。即便是資深開(kāi)發(fā)者，也需要付出巨大的努力和決心去充分理解代碼，以便將其刪除。 如果沒(méi)有 CTO 或工程副總裁定期安排時(shí)間來(lái)減少技術(shù)債務(wù)，那么由于高層的時(shí)間壓力，新添加的復(fù)制 / 粘貼代碼可能永遠(yuǎn)不會(huì)被整合到支撐長(zhǎng)期開(kāi)發(fā)速度的組件庫(kù)中。 根據(jù) GitClear 的操作，只有在單次提交中重復(fù)的代碼才會(huì)被計(jì)算。因此，2023 年測(cè)量到的 11% 的復(fù)制 / 粘貼比例，可能只是 2024 年代碼庫(kù)中悄然增加的總復(fù)制量的一小部分。修訂代碼年齡趨勢(shì)分析
我們使用了一個(gè)獨(dú)立的方法來(lái)評(píng)估 2023 年相比之前代碼質(zhì)量的變化：分析 GitClear 提供的 “代碼溯源” 數(shù)據(jù)。所謂 “代碼溯源”，其實(shí)就是要看代碼從被寫(xiě)出到最終被更新或刪除的時(shí)間長(zhǎng)度。| 年份 | 少于 2 周 | 少于一個(gè)月 | 少于一年 | 1-2 年 |
|---|---|---|---|---|
| 2020 | 65.9% | 8.7% | 21.8% | 3.6% |
| 2021 | 66.7% | 9.0% | 20.5% | 3.8% |
| 2022 | 64.7% | 9.9% | 21.1% | 4.4% |
| 2023 | 71.3% | 9.3% | 16.4% | 3.0% |
| 2024 | 74.4% | 9.1% | 14.1% | 2.4% |
解讀代碼年齡的趨勢(shì)
對(duì) “代碼溯源” 的數(shù)據(jù)分析揭示了一個(gè)有趣的現(xiàn)象，即在 2022 年到 2023 年間，代碼的更新速度加快了。特別是，不到兩周就被替換的代碼比例增加了 10%。同時(shí)，超過(guò)一個(gè)月的代碼更新頻率在 2023 年比 2022 年下降了 24%（2023 年為 19.4%，而 2022 年為 25.5%）。 這一趨勢(shì)顯示，在 AI 助手普及之前，開(kāi)發(fā)者更可能會(huì)選擇最近編寫(xiě)的代碼進(jìn)行改進(jìn)和再利用。根據(jù) Techreport 的一項(xiàng)調(diào)查 [5]，早在 2020 年代初，大約 70% 的項(xiàng)目采用了敏捷開(kāi)發(fā)方法。在敏捷方法中，每個(gè) Sprint（通常持續(xù) 2-3 周）都會(huì)規(guī)劃和執(zhí)行新的功能。這與我們的數(shù)據(jù)相符，表明大約在 2020 年左右，團(tuán)隊(duì)在每個(gè) Sprint 結(jié)束后，可能會(huì)聚在一起討論最近的工作成果，以及如何在接下來(lái)的 Sprint 中再次利用這些成果。后續(xù)研究的思考題
我們能否設(shè)定激勵(lì)措施來(lái)應(yīng)對(duì) 2024 年代碼建議引擎中普遍的 “添加后即忘記” 的問(wèn)題？ 盡管我們可以訓(xùn)練 AI 識(shí)別代碼整合的機(jī)會(huì)，關(guān)鍵在于它何時(shí)被觸發(fā)？我們需要一個(gè)新的用戶(hù)界面來(lái)復(fù)查代碼的刪除和更新，以及潛在的新增內(nèi)容。同時(shí)，那些導(dǎo)致團(tuán)隊(duì)今天無(wú)法騰出時(shí)間來(lái)減輕技術(shù)債務(wù)的管理層壓力，可能也會(huì)妨礙他們采用一種假設(shè)性的 “代碼清理” 工具。但如果有代碼助手的開(kāi)發(fā)者對(duì)探索如何整合代碼感興趣，GitClear 愿意與他們合作，詳細(xì)聯(lián)系方式見(jiàn)附錄。 另一個(gè)值得關(guān)注的問(wèn)題是：額外代碼對(duì)開(kāi)發(fā)進(jìn)度的影響速度有多大？特別是對(duì)于復(fù)制 / 粘貼的代碼，庫(kù)中代碼行數(shù)與開(kāi)發(fā)者修改這些代碼的速度之間幾乎肯定存在負(fù)相關(guān)關(guān)系。現(xiàn)在的疑問(wèn)是：“累積的復(fù)制 / 粘貼技術(shù)債務(wù)何時(shí)變得不可忽視？” 了解這種減速效應(yīng)發(fā)生的速率可以幫助未來(lái)的工具指導(dǎo)管理者何時(shí)應(yīng)該減少開(kāi)發(fā)新功能的時(shí)間。 最后一個(gè)探索的問(wèn)題是：與 2020-2022 年相比，現(xiàn)在發(fā)生的復(fù)制 / 粘貼代碼的總比例是多少？由于 GitClear 目前僅測(cè)量單個(gè)提交中的復(fù)制 / 粘貼代碼，因此整體的復(fù)制 / 粘貼量（文件中重復(fù)的所有非關(guān)鍵字、非注釋代碼行）可能是 GitClear 當(dāng)前測(cè)量值的兩倍。2024 年，復(fù)制 / 粘貼代碼真的會(huì)占到所有代碼操作的 20-25% 嗎？ GitClear 將在未來(lái)的研究中探討這些問(wèn)題，并鼓勵(lì)該領(lǐng)域的其他研究人員共享他們的數(shù)據(jù)。如果您有興趣與 GitClear 合作進(jìn)行進(jìn)一步研究，請(qǐng)查閱附錄中的聯(lián)系信息。結(jié)論：開(kāi)發(fā)者為何保持謹(jǐn)慎？
根據(jù)我們分析的兩項(xiàng)關(guān)鍵數(shù)據(jù)，2023 年代碼質(zhì)量面臨明顯下滑，這與大語(yǔ)言模型 (LLMs) 特別是 AI 代碼助手的廣泛應(yīng)用密切相關(guān)。 GitHub 與 Wakefield 研究所在 2023 年的一項(xiàng)調(diào)查顯示，開(kāi)發(fā)者已經(jīng)意識(shí)到代碼質(zhì)量的降低。當(dāng)被問(wèn)及 “在沒(méi)有 AI 的情況下，應(yīng)以哪些指標(biāo)評(píng)估你的工作？” 時(shí)，他們最關(guān)注的是 “協(xié)作和溝通”，其次是 “代碼質(zhì)量”。 但當(dāng)問(wèn)題轉(zhuǎn)向 “在使用 AI 時(shí)，應(yīng)以哪些指標(biāo)評(píng)估你的工作？” 時(shí)，他們的關(guān)注點(diǎn)發(fā)生變化，“代碼質(zhì)量” 成為了最關(guān)注的問(wèn)題，而 “生產(chǎn)事件數(shù)量” 上升為第三大關(guān)注點(diǎn)：
摘自 GitHub 關(guān)于 AI 影響的調(diào)查 盡管開(kāi)發(fā)者個(gè)人可能沒(méi)有足夠的數(shù)據(jù)來(lái)解釋為什么使用 AI 時(shí) “代碼質(zhì)量” 和 “生產(chǎn)事件” 成為更加緊迫的問(wèn)題，我們的數(shù)據(jù)提供了一個(gè)可能的解釋?zhuān)寒?dāng)開(kāi)發(fā)者被大量快速且簡(jiǎn)單的短期有效建議所淹沒(méi)時(shí)，他們往往會(huì)不斷增加代碼行數(shù)，卻忽視了檢查現(xiàn)有系統(tǒng)是否可以?xún)?yōu)化重用。 對(duì)于那些通過(guò) Tab 鍵得到復(fù)制 / 粘貼建議的經(jīng)驗(yàn)不足的開(kāi)發(fā)者來(lái)說(shuō)，解決這一問(wèn)題并非易事。工程領(lǐng)導(dǎo)們需要密切關(guān)注新數(shù)據(jù)，并思考這些數(shù)據(jù)對(duì)未來(lái)產(chǎn)品維護(hù)的潛在影響。開(kāi)發(fā)者分析工具，如 GitClear，能夠幫助識(shí)別問(wèn)題代碼的累積速度。需要考慮的關(guān)鍵問(wèn)題有：
-
代碼復(fù)用比例是否在下降？
-
代碼的移動(dòng)和復(fù)制 / 粘貼量是否有所變化？
-
開(kāi)發(fā)者發(fā)現(xiàn)代碼復(fù)用機(jī)會(huì)的難易程度如何？
引用
-
探索 AI 驅(qū)動(dòng)的開(kāi)發(fā)者生命周期帶來(lái)的經(jīng)濟(jì)效益：GitHub Copilot 的案例分析 [GitHub]
-
GitHub Copilot for Business：企業(yè)級(jí)智能編程助手 [GitHub]
-
軟件開(kāi)發(fā)領(lǐng)域的重大變革：AI 驅(qū)動(dòng)下的開(kāi)發(fā)者生命周期經(jīng)濟(jì)與生產(chǎn)力分析 [GitHub]
-
深入了解 Diff Delta 和 Commit 組 [GitClear]
-
Techreport 調(diào)查顯示：超過(guò)七成團(tuán)隊(duì)采用敏捷開(kāi)發(fā)模式 [Techreport]
-
代碼溯源：它是什么，為何重要？[GitClear]
-
調(diào)查顯示 AI 如何改變開(kāi)發(fā)者的工作體驗(yàn) [GitHub]
-
領(lǐng)略下一代開(kāi)發(fā)者生產(chǎn)力的風(fēng)采 [O’reilly]
-
當(dāng)你的代碼變成犯罪現(xiàn)場(chǎng) [Pragmatic Programmers]
-
敏捷軟件工藝中的代碼潔凈之道：實(shí)用手冊(cè)及其引用 [Robert C. Martin, 作者]
-
[JetBrains AI：提升你的編程工具，迎接新的自由 (https://www.jetbrains.com/ai/)[JetBrains]
-
Git 提交指南：深入了解 git-commit[Git 文檔]
-
如何使用 Tech Debt 瀏覽器優(yōu)化代碼 [GitClear]
-
“不要重復(fù)自己” 原則的智慧 [Wikipedia]
-
X：Adam Tornhill 分享的思考 [X/Twitter]
本文已獲授權(quán)轉(zhuǎn)載。 原文：Coding on Copilot（ https://gitclear-public.s3.us-west-2.amazonaws.com/Coding-on-Copilot-2024-Developer-Research.pdf ）
作者：William Harding,Matthew Kloster
譯文：在 Copilot 的協(xié)助下編程白皮書(shū) ——2023 年的數(shù)據(jù)顯示了代碼質(zhì)量面臨的挑戰(zhàn)（ https://baoyu.io/translations/llm/coding-on-copilot-2024-developer-research ）
譯者：寶玉
往 期 推 薦
1、美團(tuán)二面：布隆過(guò)濾器有什么用？什么原理？如何使用？
2、該死的單元測(cè)試，寫(xiě)起來(lái)到底有多痛？
3、互聯(lián)網(wǎng)人為什么學(xué)不會(huì)擺爛
4、為什么國(guó)外JetBrains做 IDE 就可以養(yǎng)活自己，國(guó)內(nèi)不行？區(qū)別在哪？
5、相比高人氣的Rust、Go，為何 Java、C 在工具層面進(jìn)展緩慢？
6、讓程序員早點(diǎn)下班的《技術(shù)寫(xiě)作指南》
點(diǎn) 分 享
點(diǎn) 收 藏
點(diǎn) 點(diǎn) 贊
點(diǎn)在看
評(píng)論
圖片
表情