改进代码审查清单的八部分指南
在当今 UI/UX 开发人员可用的所有生产力工具中,很少有像看似简单的清单那样普及和有效的工具。
在《清单革命》一书中,阿图·葛文德阐述了简单的清单如何改变我们的工作方式。葛文德在书中试图找到一种方法,帮助医生、外科医生和护士在手术室——一个生死攸关的场所——提供更好、更稳定的医疗服务。
“我们积累了惊人的专业知识,”加万德在他的书中写道。“我们把这些知识交给了社会上一些训练有素、技能精湛、勤奋努力的人。他们也确实凭借这些知识取得了非凡的成就。然而,这些专业知识往往难以驾驭。”
虽然软件开发并非生死攸关的大事,但我们可以通过使用清单的力量,在协作时有效地确定优先级,从而应用同样的经验教训。
什么是代码审查?
当团队中的软件开发人员想要将他们编写的代码贡献回主项目时,他们需要提交“拉取请求”或“合并请求”。这是开发人员为软件项目做贡献的主要方式,但有时拉取请求获得批准的速度会非常慢。
在将这段代码添加到项目之前,其他团队成员将进行代码审查。这意味着检查代码中的错误和问题,并提出改进建议。
为什么要制定代码审查清单?
总的来说,代码审查非常棒。它们能显著提高代码质量,提升开发人员的效率,并防止缺陷影响到客户。
但如果没有好的流程,代码审查用一个词来形容就是……痛苦。
代码审查清单有助于确保高效的代码审查。代码审查清单可以避免简单的错误,验证工作是否已完成,并有助于提高开发人员的绩效。
1. 拉取请求礼仪 ✅
首先从基础做起。你正在查看的拉取请求真的准备好进行代码审查了吗?为了确定这一点,以下是一些适用于所有代码审查的关键原则:
- 频繁提交——为了便于管理拉取请求,请少量多次地提交。如果一个拉取请求无故跨越数天,则应将其拆分成更小的部分。
- 精简版——如果拉取请求太大,就难以理解。应该尽可能将其拆分成更小的部分。
- 文档齐全——该拉取请求是否有足够的注释,以便于审查?
- 遵循单一职责原则——代码应该只解决一个问题。如果一段代码影响项目中的许多其他代码,那么代码审查就会变得很困难。
如果这些条件不满足,则将代码退回给贡献者进行改进,或者将其拆分为不同的拉取请求。
这起初可能看起来严厉或适得其反,但几周后,你团队的产出和生产力将会提高。
2. 造型🎨
为你的团队制定一些基本的代码风格规则,并确保这些规则得到遵守。一致的代码风格对于确保未来的开发人员能够轻松理解代码并高效工作至关重要。
一些基本规则:
- 变量名是否合理且首字母大写一致?
- 代码中是否有足够的描述性注释,符合要求?
- 是否遵循格式偏好?例如,使用制表符还是空格,花括号在同一行还是另起一行,80 个字符的宽度还是 120 个字符的宽度?
为了节省时间,您可以使用自动代码检查工具来检查这些规则是否得到遵守。Prettier就是一个适用于 JavaScript 项目的优秀示例。
再次强调,如果这些标准没有得到满足,请停止检查代码并将其退回给贡献者进行审查。
3. 安全 🔐
为您的项目制定安全标准,并确保这些标准得到严格执行。需要检查的规则会因项目和组织而异,但以下是一些最佳实践:
- 使用LGTM等漏洞扫描解决方案对您的项目进行扫描。
- 不要将测试凭据硬编码到代码中,也不要将密钥包含在代码库中。
- 不要在错误信息中透露过多信息,以免给攻击者提供线索。
- 确保所有数据库查询都已参数化
- 不要盲目信任用户或客户端的输入——您的客户端或Web应用程序可能已被修改。例如,访问资源的URL参数应该进行检查。
如果在代码审查过程中发现安全问题,请立即停止并与贡献者沟通。这可能表明项目存在更严重的问题,或者缺乏相关培训,这两种情况都需要后续干预。
4. 表演🏎
该项目的性能是否已达到最佳状态?或者说,这些是一些显而易见的优化方法,可以进一步提升性能?
例如:
- 代码中是否有任何部分可以用性能更高的库或语言原生函数来替换?
- 是否有可以移除的调试或日志记录代码?
- 如果适用,是否使用了缓存?
- 图片和素材是否经过适当压缩?
有很多工具可以帮助你优化项目的网页性能。对于前端项目,可以先从Chrome Lighthouse(也称为PageSpeed Insights)和DebugBear入手。
5. 测试🧪
测试会自动检查代码是否按预期运行,因此是代码审查过程中的关键部分。
- 首先,检查所有常用功能是否都已编写测试用例并附有完善的文档。如果某些功能没有被测试覆盖,则应详细说明原因。
- 其次,确保测试之间相互隔离,以便在测试失败时能够快速找到问题所在。
- 最后,这些测试真的测试了代码吗?通常情况下,它们声称测试了代码,但实际上并没有评估应用程序的预期功能。
如果你正在寻找自动化单元测试工具, Jest是个不错的选择。而对于自动化端到端测试,可以了解一下Cypress和Reflect。
然而,务必记住,并非所有测试都万无一失,不应完全依赖测试结果,下一项清单内容就证明了这一点……
6. 它真的有效吗?💩
这看起来很简单,但我们以前都曾做出过这样的假设。
如果你所在的团队采用敏捷迭代开发模式,代码必须始终对照产品经理或产品负责人提供的验收标准进行检查。如果代码不符合验收标准,请询问贡献代码的开发人员原因。
另一个常见问题是代码在本地运行正常,但在生产环境中却不行。所有待审查的代码都应该部署到与生产环境一致的测试环境中。这样可以避免因环境差异而导致的问题。
FeaturePeek用户无需担心测试环境和生产环境之间的不一致,因为它会在每次发起拉取请求时自动将分支部署到专用环境中。这使得审核人员能够立即看到更改,并与设计师、经理和其他非技术利益相关者分享,以获取进一步的反馈。
7. 积极的代码审查文化😻
在发送代码审查反馈或召开会议之前,请确认您的评论能够帮助团队改进,而不是被视为批评。
代码审查是你与团队其他成员之间最频繁的互动之一。务必花时间确保你以积极的方式提出代码审查反馈,这样才能长期为营造积极协作的代码审查文化做出贡献。
将批评性反馈重新表述为建设性意见会有所帮助。例如,如果代码缺少测试覆盖率,可以建议“增加测试覆盖率是否对我们有益?”以此来检验和挑战团队成员的理解。
8. 不断检查清单🤔
只有及时更新的清单才有效。因此,定期检查清单并确保其满足您的需求至关重要。
随着新成员加入或项目新增需求,您的代码审查需求也会随之改变。例如,如果您在持续集成流程中添加了新的工具,则应将其纳入代码审查范围。
FeaturePeek为代码审查人员提供了一个悬浮式 UI 界面,方便他们查看部署情况并留下宝贵的反馈。这样一来,审查人员可以更快地提供反馈,代码审查清单也能更轻松地根据最新需求进行更新。
了解更多
清单只是UI/UX开发人员用来提高效率的众多工具之一。请在下方评论区分享您的团队是如何保持高效的。
文章来源:https://dev.to/featurepeek/the-8-part-guide-to-better-code-review-checklists-1oh3