Code Review

名词解释：

cr: code review cl: change list，指这次改动 reviewer: cr的那个review人 nit: 全称nitpick，意思是鸡蛋里挑骨头 lgtm: looks good to me 【译】你知道 Code Review 应该检查哪些问题吗

代码审查清单

功能检查此代码更改是否完成了它应该做的事情？这个解决方案可以简化吗？您是否会以在代码的可维护性、可读性、性能和安全性等方面有更好的方式解决问题？代码库中是否有类似的功能？如果有，为什么不复用此功能？这段代码是否遵循面向对象的分析和设计原则，如单一职责原则、开闭原则、Liskov 替换原则、接口隔离、依赖注入？
bug 检查您能想到代码未按预期运行的任何用例吗？您能想到任何可能破坏代码的输入或外部事件吗？
依赖项检查如果此更改需要在代码之外进行更新，例如更新文档、配置、自述文件，是否已完成？这种变化是否会对系统的其他部分产生任何影响，是否已经兼容？如果代码处理用户输入，它是否解决了跨站点脚本、SQL 注入等安全漏洞，它是否进行输入清理和验证？
可用性和可访问性从可用性的角度来看，提议的解决方案是否设计良好？ API 是否有据可查？ UI 是否可访问？ API/UI 使用起来是否直观？
表现您是否认为此代码更改会对系统性能产生负面影响？您是否看到任何提高代码性能的潜力？
测试代码是否可测试？它是否有足够的自动化测试（单元/集成/系统测试）？现有的测试是否合理地涵盖了代码更改？是否有一些测试用例、输入或边缘用例需要额外测试？
可读性代码容易理解吗？哪些部分让您感到困惑，为什么？可以通过更小的方法来提高代码的可读性吗？代码的可读性可以通过不同的函数/方法或变量名来提高吗？代码是否位于正确的文件/文件夹/包中？更多注释会使代码更易于理解吗？是否可以通过使代码本身更具可读性来删除一些注释？您认为某些方法应该被重组以拥有更直观的控制流程吗？

自审代码

代码审查清单不仅适用于代码审查人员。我们应该并首先成为自己的审查者，遵循代码审查最佳实践。

因此，在发送代码进行审核之前，请确保：

代码编译并通过静态分析，没有警告代码通过所有测试（单元、集成和系统测试）您已经仔细检查了拼写错误并进行了清理（评论、待办事项等）您概述了此更改的内容，包括更改的原因和更改的内容除此之外，作为代码作者，您应该通过与审阅者相同的代码审查清单。

关注重要问题

作为代码审查员，您的任务是首先寻找最重要的问题。

结构或逻辑问题比代码格式等小问题更有价值。

一份出色的清单将您的注意力引导到重要和最有价值的问题上。

自动化编码风格及约定

清晰的编码风格指南是在代码库中强制执行一致性的唯一方法。而且，一致性使代码审查更快，允许人们轻松更改项目，并使您的代码库保持可读性和可维护性。

上文的审查清单没有介绍编码风格相关的内容，是因为我们建议使用自动化工具来强制遵守编码风格。通过安装及配置 prettier、eslint、tslint、stylelint 等格式化工具，节省编码风格的代码审查时间。

注意表达方式

最后，代码审查反馈的质量不仅取决于您在说什么，还取决于您怎么说。建议将您的反馈表述为建议而不是要求。

例如，不要写“变量名应该是 removeObject ”，而是说“调用变量 removeObject 怎么样？”。

Contributors

作者:Long Mo

字数统计:1.1k 字

阅读时长:3 分钟

Long Mo

文章作者：Long Mo

Code Review ​

代码审查清单 ​

自审代码 ​

关注重要问题 ​

自动化编码风格及约定 ​

注意表达方式 ​

Contributors ​