代码review

团队中的代码review是一个重要的课题。

现状分析和意义

大多数开发人员，所认知的代码review，就是把代码拿出来给别人看，大家讨论讨论，脑子里面没有特别深刻的概念。

其实代码review所涉及的东西包括：review的工具、review的规范、review的流程、review的方式、甚至人员参与度、时间把控等等。

代码review的意义，当然就是通过流程管理，尽可能的减少线上问题。对于TL，通过这样的过程管理，能够对项目质量把控。

当然它也有一定的缺点，增加了软件开发的流程，一定程度上降低了效率。（不过这是假设我们的项目都是高质量的，如果项目的质量本身存在问题，等到线上修复的时候，代价会大的多）

一些软性的见解

1、代码review的环境塑造

代码review是一个交流的过程，如果代码写的好，那就是展示自我的平台，向大家分享优秀的实践。

如果代码有问题，也没有关系，发现问题，并且解决问题。

一般而言，TL在这个过程的态度很重要，如果TL以一个批评的口气来说谁谁谁有问题，那天然的大家会对这件事起反感。

如果TL能在这个过程，一直输出一些优秀的思维方式，代码架构方式，其实是给底下人传授经验的过程，大家感觉有收获，自然会喜欢review。

特别的要注意态度的问题，人的情绪是非常敏感的，如果团队有人说出类似“这行代码真垃圾”这样的话，TL关注的点一定不能说这个代码的问题，而是团队中的某些人的语气问题了。

探讨别人的代码的时候，可以说，这行代码可以怎么怎么实现，表达自己的认知就行了，不要表达特殊（不好）情绪。

个人反而非常喜欢赞赏别人，比如代码量多，可以说别人这段时间幸苦了。逻辑复杂，可以说这个确实耗费了不少心力之类的话。

2、代码review——如何推动

其实人总是不想把自己的东西暴露出来，类似我写的代码，就是我的东西的感觉。

在推动代码review的时候，要从两方面下手，相辅相成。一方面是价值宣导，让大家认可这件事，认可代码review的重要性，另一方面是需要一定的强制性，因为这个是团队代码质量的需要，也是公司业务稳定性的需要。

依照个人经验，价值观宣导，可以从行业内大厂的做法，以及必要性，甚至团队成员的职业发展上说明，大概率是可以让大家认可的。

每次遇到重大问题的时候，其实也是机会，就看我们会不会利用，假如出现线上问题，提出代码review的事情，大家应该会接受。

3、代码review——不忘初心

时刻谨记，我们的目的是什么。

不要改一行样式代码，就要进行一次review。因为这个东西本身没有什么探讨的价值。

一般而言，代码量超过一定量的时候，其业务复杂度，代码的设计都是可以进行探讨的。

review的规范

review的规范，应该结合团队具体的情况，举行施行。

不过还是有一些共性的东西：比如review的要点有那些？review的参与人都有那些？review的粒度是什么？

review的要点

1、代码格式是否符合规范

这一部分包括lint规范、命名规范等。lint规范一般使用工具可以解决，但是命名是否规范需要我们去审查。

2、代码的可读性

是不是有深层的if else嵌套。

是不是有难以理解的函数、或者一个函数过于长。

比如如果是Vue项目，官方推荐的风格指南：cn.vuejs.org/v2/style-gu…

3、边界问题

是不是有开发人员没有想到的异常情况，这一般是和具体的业务场景相关。

4、代码架构

代码的组织方式，是不是有调整的空间。是不是有可复用的代码，提取出来？

参与人员

如果比较小的团队，比如三四个人，大家做的东西，应该都比较了解，可以全员参与

如果比较大型的团队，其实也是按照所熟悉的业务，分为不同的方向，相关人员可以参与reivew。

不过具体执行层面，需要具体问题，具体分析。

review的粒度

个人认为，一些简单的改动，是不需要代码review的。

但是团队成员的管理上，需要一些硬性规定，那么可以把代码量超过500行，算作一个临界点。

review的工具

review是一个系统的工程，有参与的人员、有相关规范，一定也有工具。

个人实践上，在阿里内部，其实有类似的工具。

但是考虑大多数公司可能没有自己确定的工具，那么个人推荐开源工具reviewboard。

写在最后：本文是作者专题《前端团队技术打造》的一部分，查看更多内容请看下面的文章：juejin.cn/post/685705…