送給你的代碼審查問(wèn)題手冊

代碼審查列表，是代碼審查的明確規則和指導手冊，它可以使代碼審查為你的團隊帶來(lái)更多好處，并且能夠顯著(zhù)提升代碼審查的速度。

研究表明，使用代碼審查列表的審閱者的表現要優(yōu)于不使用的審閱者。所以不管你是新手開(kāi)發(fā)者還是經(jīng)驗豐富的開(kāi)發(fā)者，開(kāi)始考慮使用代碼審查列表吧。

代碼作者應該關(guān)注的列表

作為代碼的作者，你應該保證：

• 代碼編譯成功并且通過(guò)靜態(tài)檢查（沒(méi)有警告）

• 代碼通過(guò)所有的測試（單元測試、集成測試和系統測試）

• 你已經(jīng)仔細檢查了拼寫(xiě)錯誤，并做了處理（注釋、todo等）

• 概述代碼修改的原因以及修改了哪些地方

除此之外，作為代碼作者，也應該在提交審查之前，按照審查者的列表對自己的代碼進(jìn)行審查。

代碼審查者應該關(guān)注的列表

作為代碼審查者，你的任務(wù)是尋找最重要的問(wèn)題。評論會(huì )要對代碼的結構性或邏輯性問(wèn)題更有價(jià)值，即使有時(shí)候會(huì )顯得挑剔。

你應該知道什么是好的代碼反饋。另外需要注意，最好的代碼審查反饋不是點(diǎn)評，而是建議。所以不要說(shuō)“變量名稱(chēng)應該是removeObject“，最好說(shuō)”調用變量removeObject怎么樣？“。

下面這份列表足夠幫助你提出好的代碼審查反饋了。

實(shí)現

• 此代碼更改會(huì )執行它應該做的事情嗎？

• 這種解決方法是最簡(jiǎn)單的嗎？

• 這個(gè)更改有引入一些不需要的編譯時(shí)或運行時(shí)的依賴(lài)嗎？

• 是否使用了不應該使用的框架、API、庫、服務(wù)？

• 是否存在可以提升解決方法的未使用的框架、API、庫、服務(wù)？

• 代碼是否處于正確的抽象級別？

• 代碼是否的模塊化做的是否足夠好？

• 你是否有其他的解決方案，該方案在代碼可維護性、可讀性、性能、安全方面表現更好？

• 是否已經(jīng)存在類(lèi)似功能的函數？如果有，為什么不復用？

• 是否有最佳實(shí)踐、設計模式或特定語(yǔ)言模式可以?xún)?yōu)化代碼？

• 代碼是否遵循面向對象的分析和設計原則，例如單一責任原則，開(kāi)閉原則，里氏替換原則，接口隔離，依賴(lài)注入？

邏輯錯誤或Bug

• 你能想到代碼不按預期運行的任何用例嗎？

• 你能想到任何可能破壞代碼的輸入或外部事件嗎？

錯誤處理和日志

• 錯誤都被正確處理了嗎？

• 是否有需要增加或刪除的日志/debug信息？

• 錯誤消息對用戶(hù)是否友好？

• 是否有足夠的日志，它們的編寫(xiě)方式是否是易于調試的？

可用性和可訪(fǎng)問(wèn)性

• 從可用性角度出發(fā)，所提出的解決方案是否設計合理？

• API文檔是否足夠好？

• 提出的解決方案是否具備可訪(fǎng)問(wèn)性？

• API/UI是否直觀(guān)易用？

測試與可測試性

• 代碼是否達到可測試標準？

• 是否有足夠的自動(dòng)化測試（單元測試/集成測試/系統測試）？

• 現有測試是否合理覆蓋代碼變更？

• 是否有額外的測試用例、輸入或邊界用例以供測試？

依賴(lài)

• 如果這個(gè)修改需要更新代碼以外的文件，例如更新文檔，配置，readme文件。是否完成了這些更新？

• 這個(gè)修改是否會(huì )對系統其他地方造成影響？是否能夠向后兼容？

安全和隱私數據

• 這段代碼是否打開(kāi)軟件的安全漏洞？

• 權限和身份驗證是否被正確處理？

• 是否安全處理了敏感數據，例如用戶(hù)數據、信用卡信息等？是否正確使用加密方法？

• 代碼更改是否顯露了一些私密信息（如迷藥，用戶(hù)名等）？

• 如果代碼處理用戶(hù)輸入，是否解決了跨站點(diǎn)腳本，SQL注入等安全漏洞，是否進(jìn)行了輸入清洗和驗證？

• 從外部API或庫中獲得的數據是否進(jìn)行了相應的檢查？

性能

• 這段代碼修改是否會(huì )對系統性能產(chǎn)生負面影響？

• 是否可以進(jìn)一步提升代碼性能？

可讀性

• 代碼是否容易理解？

• 哪一部分使你困惑，為什么？

• 可以通過(guò)減小方法來(lái)提高代碼可讀性嗎？

• 可以通過(guò)使用不同的函數/方法或變量名稱(chēng)來(lái)提升代碼可讀性嗎？

• 代碼是否存放在正確的文件/目錄/包？

• 你是否認為方法應該重構以擁有更直觀(guān)的控制流程？

• 數據流是否可理解？

• 是否有多余的注釋?zhuān)?/p>

• 某些注釋是否可以更好的傳達信息？

• 是否更多的注釋會(huì )使你的代碼更容易理解？

• 是否可以移除一些注釋?zhuān)ㄟ^(guò)提升代碼可讀性來(lái)理解代碼？

• 是否存在注釋掉的代碼？

專(zhuān)家意見(jiàn)

• 你是否認為特定專(zhuān)家（如安全專(zhuān)家或可用性專(zhuān)家）應該先檢查代碼，然后再提交代碼？

• 這個(gè)代碼修改會(huì )影響其他團隊嗎？他們也應該發(fā)表意見(jiàn)嗎？

好了，以上就是最為緊迫的一些問(wèn)題列表。

代碼風(fēng)格和約定

您的團隊或公司必須擁有清晰的編碼風(fēng)格指南，這一點(diǎn)很重要。因為這是在代碼庫中實(shí)施唯一性的唯一方法。并且一致性會(huì )使代碼審查更快，使人們可以輕松地更改項目，并保持您代碼的可讀性和可維護性。

Google是做到這一點(diǎn)的很好的例子，無(wú)疑，這使Google可以進(jìn)行快速的代碼審查。

首先，我建議使用現成的編碼樣式來(lái)支持Google提供的多種語(yǔ)言。設定基本規則很重要，但要確保一勞永逸。不要持續爭論。

盡可能自動(dòng)化

確定了代碼風(fēng)格以后，請花一些時(shí)間正確安裝和配置工具，以便一鍵格式化代碼。

另外還有很多事情可以做。例如使用靜態(tài)檢查來(lái)代替部分人工審核。這是值得為之努力的。

完整問(wèn)題列表

原文轉自：https://www.michaelagreiler.com/code-review-checklist/