执行代码审查的三个小技巧

执行代码审查是识别错误、共享知识和创建高质量产品的有效机制。不幸的是,大多数开发人员宁愿拥有根管道,也不愿意参加代码审查。他们常常感到痛苦和无所作为。您是否曾经尝试过创建一个团队习惯,即代码审查,却发现它在几个星期后就会失败?或者你的代码评审不会带来时间投资的回报?

在今天的帖子中,我们将探索几个技巧,以帮助您实现代码评审的现代化,从而获得开发人员的支持,并使您更加有效。

提示1-执行"离线"代码评审

我从来不喜欢传统的代码评论。这些"在线"代码评审让一组开发人员进入同一个房间来阅读代码。应该有记录员、阅读员和其他各种角色。读者说明代码应该做什么,并在十几位同事坐在旁边听的时候逐行阅读,如果他们能保持清醒的话,偶尔提供反馈。

在线代码评审有很多问题。例如,当许多团队成员在一个房间里时,工作要有效率。你很可能会被转移话题,被迫不断地把话题带回评论上来。为了获得成功,你应该限制你花多少时间,每次只花一个小时来审查代码。你应该将审查限制在不超过400行代码的范围内,这样才是最有效的。

这些是很好的指导方针,并已证明是有效的。但是当12个团队成员每天产生100个LOC时,你会怎么做呢?你需要团队中的每个人每天进行三个小时的代码评审!在某种程度上,劳动力成本和投资回报是相互竞争的.

在线代码评审的另一种选择是脱机进行评审。不要让每个人都呆在一个房间里,而是使用你的软件管理框架进行代码评审。我最喜欢的流程之一是在合并请求之前不执行代码审查。你和你的团队应该经常承诺和合并。合并请求不是让团队成员审查代码、添加注释和反馈的最佳时机吗?

在合并请求中,您可以允许队友在合并截止日期之前休闲地审查代码。在代码合并之前,开发人员有机会进行这些改进。希望他们能事先验证行为和识别任何错误。

提示#2-编写和评论"离线"评论的代码

在执行代码审查时,通常遵循一个标准过程。它通常涉及:

· 从代码模块的概述开始,了解其目的和功能。

· 逐行审查代码,检查语法错误、逻辑问题和是否符合编码标准

· 查明潜在的缺陷、安全漏洞或需要改进的领域

如果你在代码评审的基础上编写和评论你的代码,你的团队在合并请求下执行离线评审会容易得多。例如,你应该在你的模块中记录你对模块及其目的的概述!该函数的目的是什么,您所做的以这种方式编写它的决定应该记录在案!

如果你编写你的代码以便能够很容易地对代码进行审查,你会发现你的团队可以在没有在同一个房间的情况下审查代码。它们可以在管理工具中进行注释,您可以在提交最终合并请求之前收集和修改该工具。

提示3-分配小型评审团队

每个开发人员都很愿意查阅代码库中的每一行代码。它有助于填写系统中每个部分的细节。然而,对于今天的许多嵌入式产品来说,这个系统太大了,过于复杂,无法实现。相反,对于团队来说,确保每一行代码都经过审查,但只由某些人进行审查,这更有意义。

将代码审查过程分解为小型团队是确保产品中每一行代码都得到审查的一个很好的方法,但有时只是由每个人进行。开发人员A可能会让开发人员B和C审查他们的代码。同时,开发人员B由开发人员C和D评审等.虽然每个审查模块的开发人员都能提供独特的见解,但我们可以通过将每个代码的审查者人数限制在合理的数量范围内,更有效地执行代码审查。

平衡审查特定模块的团队的规模,可以帮助平衡代码审查的好处,同时又不会阻碍开发团队。帮助确保团队仍然在生产代码,同时确保生产的产品质量合理。

代码回顾小贴士

在嵌入式软件中进行代码审查的必要性是至关重要的,但我认为它们是团队放弃的第一个也是最简单的过程。前三条提示让您深入了解如何简化流程,同时从代码审查中获得深刻见解和益处。代码评审非常重要,我想多给你几个建议会很有意思:

· 培养建设性的反馈环境。反馈不是对开发人员完成工作能力的判断。

· 为守则的审查、更正和定稿设定一个时间表。

· 利用人工智能工具提供初步的反馈列表.(这可能是将来代码评审的方式)

· 除非代码通过了测试,否则不要审查代码

· 不要审查代码,除非它已经传递了行行的代码样式

· 让代码审查成为你日常习惯的一部分(只要有合并请求)

· 玩得开心点。代码评论是一个很好的机会,与你的队友积极接触和学习!别以为你什么都知道!

结论

代码审查提高了代码质量、可读性、可维护性和团队协作。传统的代码审查方法最好的情况是痛苦的,最坏的情况是浪费时间。不一定非要这样。

在这篇文章中,我们探讨了一些可以用来帮助改进代码评审的技巧。通过正确地编写代码和利用现代协作工具,您应该能够实现代码审查提供的所有好处,同时使它们更容易被接受。