code review

作者：腾讯Bugly
链接：https://www.zhihu.com/question/41089988/answer/135943884
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

什么样的团队需要进行CodeReview活动？

CodeReview作为业界公认的最佳实践，如果每个团队都能运用起来，固然是最好的，但是由于这项活动跟“人”这个因素密切挂钩，所以，它是否能有效运作跟团队状态、技术信仰和领导者诉求等都有莫大关系。今天，笔者想分享下个人在“到底什么样的团队需要”和“什么样的团队暂时不适合”这方面的思考。这里欢迎大家更多的交流讨论。

从代码质量提升的角度上看，以下类型的团队，笔者建议把CodeReview活动有效运作起来：

1. 技术驱动型团队：一般涉及系统底层逻辑较多，功能路径难以被测试覆盖，而产品质量问题很多时候是致命的，所以这样的团队更多需要开发编码的严谨性和相关代码质量的保证活动。手机管家高权限应用组就属于这一类型。

2. 公共服务型团队：一般服务于多个团队，一旦出现质量问题影响范围会比较广，所以除了在测试方面加以把关外，通过CodeReview活动来提升开发质量是非常有必要的。

3. 测试缺失型团队：这样的团队由于缺乏测试环节，质量问题带到线上的风险会很高，强烈建议在开发环节做好自检工作。

4. 新人密集型团队：新人的代码可读性往往是比较差的，特别需要组织能及时给予纠正，帮助新人养成良好的编码习惯。同时如果团队产出的代码可读性较高时，新人也可以更快上手工作。

5. 任何有主观意愿的团队：这样的团队或领导者认同CodeReview的意义，或团队成员对代码质量提升有追求。

CodeReview活动跟人这个因素密切相关，从其带有的这个主观特点来说，笔者认为以下类型的团队暂时不适合开展CodeReview活动：

1. 不认同型团队：即领导和团队骨干都不认同CodeReview意义的团队，这样的团队无论从推动还是坚持上都有很大挑战。

2. 疲于应付型团队：这种团队一般没有建立必要的持续提升机制，每天淹没在各种需求沟通实现变更和优化中，自然，代码质量提升活动也很难被列入backlog。

3. 创新型团队：这种团队的重要任务是要把产品快速推向市场进行价值验证，所以在代码编写上要求足够敏捷，代码暂时的混乱完全可以接受。

综上，笔者建议大家在考虑自身团队是否要推行CodeReview时，可结合团队实际状态进行综合考虑。但一般来说，如团队主观意愿没有问题，就可以大胆推行开展。