作者：京東科技 王丹迪

刪除代碼是軟件開(kāi)發(fā)過(guò)程中常見(jiàn)的一部分，但必須謹(jǐn)慎操作以確保不會(huì)引入錯(cuò)誤或破壞現(xiàn)有功能。有效的做系統(tǒng)瘦身會(huì)降低維護(hù)成本，減少冗余代碼，減少開(kāi)發(fā)同事踩坑的機(jī)會(huì)。以下是幾個(gè)步驟和建議，幫助你更安全有效地刪除代碼：

確定范圍

優(yōu)化總是被鼓勵(lì)的，但方式和時(shí)間是同時(shí)需要被考慮進(jìn)去的因素

方式：這個(gè)方案是否好，有無(wú)漏洞？投入產(chǎn)出效益比如何？

時(shí)間：是否要在這個(gè)版本，哪個(gè)版本能使所有開(kāi)發(fā)投入時(shí)間最少（建議跟著需求一起，使測(cè)試范圍一致）

文檔：若為專門的優(yōu)化版本，則建議維護(hù)一份改動(dòng)文檔，方便回顧、檢查、及同步相關(guān)人

備份/新建分支：

在開(kāi)始之前，創(chuàng)建項(xiàng)目的完整備份。

使用版本控制系統(tǒng)（如 Git）進(jìn)行分支管理，以便可以輕松回滾更改。

理解要?jiǎng)h除的內(nèi)容：

確保你完全理解將要?jiǎng)h除的代碼的作用及其依賴關(guān)系，做到這一點(diǎn)，業(yè)務(wù)流程圖和代碼流程圖也許能更好的幫你一目了然。

如果不確定，詢問(wèn)同事或查看文檔，但應(yīng)當(dāng)注意，這里的信息不應(yīng)被完全依賴，它只能作為理解代碼的背景渠道。

測(cè)試：

在刪除代碼前后運(yùn)行所有的自動(dòng)化測(cè)試。

手動(dòng)測(cè)試受影響的區(qū)域，特別是那些與用戶界面交互部分。

逐步刪除：

而不是一次性刪除大量代碼，嘗試分階段刪除。

刪除一小部分后立即測(cè)試，確保沒(méi)有引入新的問(wèn)題。

注釋而非直接刪除：

如果你不確定是否應(yīng)該永久刪除某些代碼，可以先將其注釋掉而不是直接刪除，并且加告警以備線上出現(xiàn)問(wèn)題。（要知道，用告警的方式反饋問(wèn)題是一個(gè)非常被動(dòng)的選擇，這應(yīng)該是你在測(cè)試環(huán)境已經(jīng)確定過(guò)后的代碼，所以梳理這邊的邏輯自查并同步測(cè)試才是首要任務(wù)哦）

這樣做可以讓你以后更容易地恢復(fù)這部分代碼。

清理：

下游檢查：刪除不再需要的文件、變量、函數(shù)、接口、混入和方法等，這一步總是會(huì)被輕易忽視。

上游檢查：檢查其他可能引用已刪除代碼的地方

全局搜索：如果判斷所刪除的對(duì)象的關(guān)鍵字可能為動(dòng)態(tài)拼接，則此時(shí)選擇部分字符進(jìn)行匹配，不選擇【match whole word】；如果判斷關(guān)鍵字可能使用類似toLowerCase方法，則不選擇【match case】

如果有依賴內(nèi)部組件庫(kù)記得也要搜索一下關(guān)鍵字哦

確保所有相關(guān)的文檔和注釋也被更新。

如果有abtest下線，則記得將測(cè)試、生產(chǎn)ab平臺(tái)的相關(guān)版本也一并下線，或備注，以防他人在不知情的情況下更改配置導(dǎo)致產(chǎn)生問(wèn)題

提交和記錄：

將你的更改提交到版本控制系統(tǒng)中，提交之前的二次確認(rèn)也很重要哦。

提供清晰的提交消息commit解釋為什么要?jiǎng)h除這段代碼。

review：

讓團(tuán)隊(duì)成員review你的變更。

特別是對(duì)于那些不經(jīng)常接觸的代碼部分，審查尤為重要。

監(jiān)控：

發(fā)布更改后的軟件后，密切監(jiān)控日志和用戶反饋，以便及時(shí)發(fā)現(xiàn)任何潛在的問(wèn)題。

通過(guò)遵循這些步驟，你可以減少因誤刪代碼而導(dǎo)致的風(fēng)險(xiǎn)，并保持代碼庫(kù)的健康和可維護(hù)性。記住，在任何時(shí)候都要小心行事，特別是在涉及關(guān)鍵業(yè)務(wù)邏輯的情況下。

審核編輯 黃宇