pull-request - 代码审查的主要考虑因素是什么?
问题描述
代码审查今天非常流行。
如果我编写的代码有效并且有测试来证明它,为什么我需要额外的“竖起大拇指”呢?
是否只是为了检查我没有犯任何我编写的测试未涵盖的错误?
解决方案
代码审查的一个目的是确保代码正常工作并且测试反映了这一点。
然而,这可能带来的好处有限,因为许多组织将其视为满足组织或监管要求的“竖起大拇指”练习。
我发现一个好的拉取请求/代码审查系统背后的真正价值是多方面的,远远超出了“代码是否正常工作?”。
可以通过多种方式编写代码来实现相同的目的。
一个好的代码审查将在许多因素上检查代码,而不仅仅是“它是否运行”。
这些因素可能包括以下一些:
- 有测试吗?
- 测试质量高吗?
- 是否考虑了安全问题?
- 是否很好地覆盖了负面测试用例?
- 是否处理了错误输入数据的异常?
- 代码是否与任何依赖项隔离?
- 代码将来容易更改吗?
- 代码是否足够有效?
- 代码是否易于阅读——即使是新手?
- 代码是否干燥,避免复制和粘贴模式?
- 代码是否遵循一般或现有的组织设计模式?
- 是否使用完整的英语来避免未来对首字母缩写词和符号的认知负担?
在更高的层次上,代码审查还具有以下目的:
- 对团队的其他成员进行有关更改的教育
- 鼓励不同的观点和方法
- 避免与代码所有权相关的“忍者”/“英雄”总线问题
- 向非团队成员提供可见性,例如 QA 和其他团队
推荐阅读
- javascript - 未捕获的类型错误:无法在“XMLSerializer”上执行“serializeToString”:无法将 svg(使用 D3.js 创建)下载为 png/pdf
- typescript - 代码未在 ngOnInit(){} 中按所需顺序运行
- r - 在 R 中的带状图中使用 text3D
- git - 我做了一个 git pull origin
在开发这不是我想做的 - excel - 运行时错误 429 - Active X 无法发送电子邮件
- debugging - Azure 机器人服务中的跟踪
- sql - 组合复杂查询,从 4 个表中选择
- gradle - Gradle 5:BOM 依赖项未写入 pom 文件
- visual-studio - 由于 AJAX 错误,清除 IE 的 IIS Express 缓存
- typescript - 从 wsdl 在 typescript 中创建肥皂客户端