进行代码审查是发现bug、共享知识和创建高质量产品的有效机制。不幸的是,大多数开发人员宁愿等着报错也不愿参加代码审查。因为他们常常对代码审查感到痛苦并且感觉毫无成效。您是否曾试图培养团队的代码审查习惯,却发现几周后就不了了之?或者您对代码审查投入的时间并没有获得回报?
在今天的文章中,我们将探讨一些技巧,帮助您实现代码审查现代化,从而获得开发人员的认可并提高您的效率。
我一直都不太喜欢传统的代码审查。这些“在线”代码审查需要让一队开发人员在同一个房间里通读代码。应该有一个记录员、一个阅读者和各种其他角色。阅读者陈述代码应该做什么,然后开始逐行阅读,而十几个同事坐在旁边听,如果他们可以保持清醒,偶尔也会提供反馈意见。
在线代码审查存在很多问题。例如,当许多团队成员共处一室时,要想提高效率就需要付出努力。我们很可能会走神,不得不不断把话题拉回到审查上来。为了获得成功,我们应该限制花在审查代码上的时间,并且每次审查不超过一个小时。为了达到最佳效果,我们应该限制审查的代码行数不超过400行。
这些都是很好的指导原则,并且已被证明是有效的。但是,当12名团队成员每天生成100个LOC(可执行代码行数)时,您该怎么办?我们需要团队中的每个人每天进行三小时的代码审查!在某些时候,人力成本和投资回报是相互竞争的。
除在线代码审查外,另一种方法是离线审查。与其把所有人召集到一个房间,不如使用软件管理框架进行代码审查。我最喜欢的做事方法之一就是在合并请求之前不执行代码审查。您和您的团队应该经常进行提交和合并代码。合并请求不正是让团队成员审查代码、添加评论和反馈的最佳时机吗?
在合并请求时,我们可以允许团队成员在合并截止日期之前的闲暇时检查代码。开发人员就有机会在合并代码之前做出改进。希望他们能够验证行为并提前找出所有bug。
在进行代码审查时,通常会遵循一个标准程序。通常包括:
如果您在编写和注释代码时考虑到代码审查,那么您的团队在合并请求时执行离线审查会容易得多。例如,您对模块及其用途的概述应该记录在您的模块中!该函数的目的是什么,以及您在编写该函数时做出的决定都应记录在案!
如果您编写的代码可以轻松地进行代码审查,您会发现您的团队无需聚集在同一个房间就可以审查代码。他们可以在您的管理工具中发表评论,您可以在提交最终合并请求之前收集这些评论并进行修改。
单个开发人员都希望审查代码库中的每一行代码。这有助于填补系统每一部分的细节。然而,对于当今的许多嵌入式产品来说,系统太大且太复杂,无法实现这一点。相反,对于团队来说,确保每一行代码都经过审查更有意义(但仅限某些人)。
将代码审查流程分解为若干个小型团队是确保产品中的每一行代码都得到审查的绝佳方法,但也有时每个人都要进行审查。开发人员A的代码可能会由开发人员B和C进行审核。同时,开发人员B会由开发人员C和D进行审核,依此类推。诚然,每个审查模块的开发人员都会提供独特的见解,但我们可以通过将每段代码的审查人数限制在合理的范围内,来更有效地执行代码审查。
平衡审查特定模块的团队规模可以帮助获得代码审查的好处,同时不会让开发团队陷入困境。有助于确保团队仍在生产代码的同时,确保所生产的代码具有合理的质量。
嵌入式软件中代码审查的需求至关重要,但在我看来,代码审查是团队最容易丢弃的第一个也是最直接的流程。前面的三个技巧让您深入了解了如何简化流程,同时从代码审查中获得见解和好处。代码审查非常重要,因此我认为向您提供一些额外的提示会很有用:
代码审查可以提高代码质量、可读性、可维护性和团队协作。传统的代码审查方法往好了说是痛苦的,往坏了说是浪费时间。其实大可不必如此。
在这篇文章中,我们探讨了一些技巧,您可以利用这些技巧来帮助改进执行代码审查的方式。通过正确编写代码并利用现代协作工具,您应该能够实现代码审查带来的所有好处,同时使它们更容易接受。没有借口了!如果您还没有代码审查流程,请使用这些技巧开始吧。如果您有代码审查流程,我希望这些技巧能帮助您加强代码审查。
祝你好运,编程愉快!
(原文刊登于EDN姊妹网站Embedded,参考链接:3 tips for performing code reviews,由Ricardo Xie编译。)