课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
对于大多数的程序员来说应该都经历过代码审查这样的一个测试和考验环节了,今天我们就一起来了解一下,关于代码审查我们需要注意哪些问题。
“代码审查(code review)”这一术语可以指一系列活动,从简单地站在队友身后读读代码,到 20 人与会的单行代码分析。我用这一术语指正式的、书面的过程,但也不像一系列现场代码审查会议那么重大。
代码审查的参与者包括作者以及审查者:作者写代码并把代码送去审查,审查者读代码并决定代码什么时候就绪并入团队的代码库。一次审查可以由多个审查者完成,但是我做了简化的假设——你是的审查者。
在代码审查开始之前,作者必须创建一个变更表。作者想要将源代码并入团队代码库,变更表包括一系列源代码的变更。
当作者把变更表发给审查者时,审查就开始了。代码审查是循环发生的。每个循环都是作者与审查者之间完整的往返:作者发送变更,审查者给予变更的书面反馈。每次代码审查都包括一次或者更多的循环。
当审查者批准了这些变更,审查结束。这通常指的是给出 LGTM,“我觉得不错(looks good to me)”的简写。
关于风格的争论浪费了审查的时间。一致的风格确实重要,但是代码审查不是争论花括号位置的时候。在审查中消除风格争论的佳办法是,遵守一个风格指南。
好的风格指南不仅定义了像命名习惯或者空白规则这样的表面元素,而且定义了怎样使用给定编程语言的特征。比如,JavaScript 和 Perl 都包含了一些功能——他们提供了许多实现相同逻辑的方法。风格指南定义了做事的方法,这样不会以一半队员用了一组语言特征而另一半队员用了完全不同的一组特征收尾。
一旦有了一个风格指南,你就不需要浪费审查循环,来跟作者争论到底谁的命名习惯好。只要遵从风格指南然后继续就行。如果你的风格指南没有指定某个特定问题的约定,那它一般都不值得争论。如果你遇到一个风格指南未涉及的问题,它又重要到需要讨论,和团队一起推敲。然后把决定加到风格指南,这样你们永远不需要再进行一次这个讨论。
在一个既定的审查循环中,你写的批注越多,让作者感觉受打压的风险越大。准确的界限随开发者的不同而不同,但是一个审查循环中 20 到 50 个批注一般是危险区的开始。
如果你担心把作者淹没在批注的海洋里,约束你自己在早期循环中反馈高级别的问题。注意重新设计类接口或者拆分复杂函数这样的问题。等到这些问题都解决了再去处理低级别的问题,比如变量命名或者代码评论的清晰度。
一旦作者整合了你高级别的批注,低级别的批注可能会变得无意义。把低级别的批注推迟到后期的循环中,你可以把自己从小心措辞的工作中解救出来,也免得作者处理不必要的批注。这个技巧也细分了审查过程中你所关注的抽象层,帮助你和作者用清晰、系统的方法完成变更表。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。