代碼審查完整指南來了!
翻譯-
2024-07-11 11:09:48
-
2460
本篇目錄
代码审查不是战场,审查员也不是作者的对手。他们的目标是一致的——解决産品问题并创建高质量的代码库。讓我們深入探討並了解如何從審查者的角度進行一次代碼審查。
不要浪費時間
總有些問題時常重複出現。先是在一個拉取請求中,然後又在另一個拉取請求中;先是來自一個作者,然後又來自另一個作者。這些問題完全相同,這就是例行公事。事實上,如果某件事情可以自動化,那麽它就必須自動化。
代碼風格。没有必要为代碼風格而争论不休,因为早在几十年前,项目中的每个人或整个社区就已经对代碼風格进行了多次定义。在 linter(代码检查工具) 和 formatter(格式化工具) 中设置字符串的长度、方法和类的名称,然后忘掉它吧。
測試。要将所有測試(单元測試、集成測試、端到端測試)及其启动、覆盖范围等相关事项實現自动化。只需进行设置,并为指标设定一个可接受的阈值,例如,在 PR(拉取请求)中的新代码覆盖率不应低于 90%,这种简单的设置能让很多人的工作更轻松。
不要自我重複(DRY)。应该将常见的重复内容集中到一个地方,以便对其进行简单、集中的更改或修复。收集所有应用程序的代码重复百分比,并以相同的方式进行測試。
代碼分析。代碼分析有助于收集更多数据和指标。它不仅会检查审查中的代码,还会检查如何将其集成到现有生态系统中。一些分析工具会根据历史案例提供可能存在的漏洞或安全热点报告。将存储库与代碼分析工具集成,并在每次代码审查时运行这些工具。
總結。工程師應該專注于解決問題,而不是重複常規。我可以保證的是,如果能將上述任何事件至少基本自動化,代碼審查的平均質量就會大幅提高。這能爲審查人員節省時間。如果出現以下情況,就需要檢查代碼?
- 并非所有測試都通过
- 測試覆盖率不足/低于公认的百分比
- 代碼重複率高于可接受水平
- 代碼有異味
- 意外的安全熱點
通用規則
尊重。礼貌待人,尊重作者。请记住,代码审查的参与者是来互相幫助的,他们有着共同的目标。可以批评代码,但绝不能批评人。
任務。在完全理解问题所在之前,不要进行代码审查。获取有关问题所在、实际案例、条件、重现步骤、功能受众等信息。要求进行代码演示、代码评审会议,甚至只是同步会议,以明确特定任務的各个方面。
建議。当提出任何改变的建議时,解释原因。提供背景、示例、细节和信息,并分享有关资源的链接——为什么作者应该进行更新。一个词或一行话的评论有时真的很难理解。请记住,通常任務可能有多个解决方案,因此在建議更改之前,请尝试理解选择此解决方案的确切原因。使用提交历史,以及带有良好消息的结构化提交可以提供理解的关键。
審查流程
下面我收集了一些真正值得關注的基本類別和問題,按照優先級從最重要的開始排序。
業務目標
深入研究,不仅要研究代码,还要研究其背后的业务逻辑。首先,任何代码都必须执行指定的任務并达到指定的目标。不管代码有多好,不管它写得有多好,如果它不能實現它的目标,它就是无用的。代码不是为代码而写的。编写代码是为了添加新功能,开发和推动産品向前发展。不要将检查限制在快乐路径上,要考虑边缘情况以及如何处理它们。所有这些都可以概括为这个问题——它能解决问题吗?
實現
接下來,開始關注數字、指標和報告。從不同角度分析代碼。
安全性。它带来了漏洞还是解决了漏洞?在受到攻击时它会有多稳定?被动还是主动?比如分布式拒绝服務攻击(DDoS)或者任何类型的注入(如 SQL 注入、跨站脚本等)?
錯誤處理。如何正確處理錯誤?應用程序會崩潰或向錯誤跟蹤軟件發送報告嗎?它會向最終用戶顯示所有堆棧跟蹤嗎?它是可恢複的失敗操作嗎?數據會被損壞或碰撞嗎?
性能。新更改後性能是否受到影響?該代碼可能導致內存泄漏?優化有多好?是否做了所有的事情來使代碼高效(緩存系統、資源池、數據壓縮等)?
集成。它如何与其他模块和系统协同工作?是否能提高代码的一致性?能否方便地与其他實現或集成进行交换?代码与系统其他部分其他版本的兼容性如何(如新版本的向后兼容性)?
日志和跟蹤。这可以简化调试和故障排除过程,也可以使其变得更加复杂。例如,记录集成的第三方服務的响应时间有助于识别停机时间。日志和跟蹤是否足够?多还是少?
仔細研究並回答這些問題,就能確定實施工具的正確選擇。
可維護性
這裏的一個主要問題是——“沒有作者的代碼如何生存?”
可讀性。代碼如同構成單詞或者句子的字母,所有的代碼組成完成後,就如同在閱讀一本書籍,不過這本“書籍”是用一種特定的語言寫的:編程語言。所以可讀性应该从字面上理解,代码应该用写得好的字符(如参数、变量等)构建一个故事(如类、函数),它们应该采取行动(调用其他函数、变异或不可变等)。
值得關注的問題:该代码的可讀性如何?它可以由作者以外的人来维护吗?命名参数、变量、函数等的可理解性如何等等。
文檔。在开发过程中,文檔可以节省大量时间,减少同步时间,简化入职流程,总之是项目知识库的良好存储。
值得關注的問題:代码文檔的质量如何?阅读后是否会留下疑问?所有需要的 MD 文件和外部文檔是否会根据变更进行添加/更新?
可重用性。爲防止代碼重複,如果多個模塊的邏輯是共通的,就可將其移至助手、實用程序等共享位置。
值得關注的問題:代碼的某些部分能否在其他地方重複使用?如果不能,其獨特性是否合理?如果是,是否爲達到這一指標而進行了過度設計?
設計。代码不应该重新发明轮子。在社区中已经有许多被认可的最佳实践和定义好的設計模式,它们是软件工程中常見問題的解决方案。
值得關注的問題:代碼是否采用了最佳實踐和模式?是否以正確的方式使用?
印象。代碼應當激勵以某種方式與它現在或未來産生交集的任何人,努力做到同樣出色和高質量,甚至更好。
值得關注的問題:在合並之後,代碼庫是否變得更好?其他工程師會對使用這段代碼感到興奮嗎?
代碼審查:成長的機會
做好代碼審查是一項艱巨的工作。審核員是第一道技術質量關。在合並之前,代碼歸作者所有並由其管理,但合並之後,責任將移交給整個團隊。這就是爲什麽審查員應該關注代碼的穩定、可靠和無懈可擊。代碼審查是一次成長的機會。對審閱者和作者來說都是成長。
-
禅道産品
禅道開源版 禅道企業版 禅道旗艦版 禅道IPD版 -
核心功能
産品管理 項目管理 質量管理 效能管理 -
使用文檔
基本版手冊 企業版手冊 旗艦版手冊 IPD版手冊 開發中心手冊 -
幫助中心
积分問答 常見問題 論壇交流 使用視頻 Gitee GitHub -
關于我們
關于我們 禅道軟件 最新動態 禅道活動 -
禅道社區
禅道博客 積分排行 積分商城 禅道書院 -
聯系方式
聯系人:劉斌 電話:17685869372 微信:17685869372 Q Q:526288068北京、上海、深圳分部