熊节:极限追问032

【代码评审（code review）怎么做？】

背景:代码评审似乎是大家都愿意接受的良好实践，用不大的投入能对质量产生较大的提升。请大家分享一些做代码评审的经验。

分问题1:你的团队在什么时候做代码评审？

分问题2:哪些代码需要被评审？

分问题3:谁来做评审？

分问题4:评审哪些内容？

分问题5:评审过程中发现问题怎么办？

Page

熊节:极限追问032

【代码评审（code review）怎么做？】

背景:代码评审似乎是大家都愿意接受的良好实践，用不大的投入能对质量产生较大的提升。请大家分享一些做代码评审的经验。

分问题1:你的团队在什么时候做代码评审？

两个场景下做Code Review：

（1）个人代码提交前做Code Review。Review自己将要Commit的代码。 （2）团队每日Code Review。不同的项目按照团队约定时间进行，可以在一天的开始或者将要结束的时候进行。

分问题2:哪些代码需要被评审？

（1）个人所有需要提交的代码需要在Commit之前Review （2）团队Code Review。需要Review所有被提交的代码。有时候团队内会存在前端和后端。可以选择一起做Code Review，也可以选择分开。 （3）以上两种情况，需要关注代码和Commit信息。代码中需要关注业务代码，测试代码，以及当天的测试核心代码覆盖率等信息。

分问题3:谁来做评审？

参与Code Review的所有人共同参与。形式有多种，比如
形式一：代码提交者自己来讲，最改了什么，为什么，团队共同发现优点和缺陷 形式二：团队中的其他人来讲，这段代码在做什么，团队共同发现优点和缺陷

分问题4:评审哪些内容？

（1）可以按照提交记录逐条进行Code Review，看到代码的演进；也可以review多次提交的结果集。 （2）Code Review时，需要关注Commit记录和代码，Commit记录需要直白的描述当次提交的目的。 （3）Review 代码时，需要识别出代码中好的实现，不好的实现。 （4）针对问题，表明观点并达成团队共识。

分问题5:评审过程中发现问题怎么办？

（1）首先划定个讨论的范围，确定讨论将会聚焦。描述清楚是什么问题，为什么有这个问题，有哪些解决办法。 （2）避免只是挑错。Code Review时团队内学习的过程，同时也是开发团队思路达成共识的过程，不会针对某个人，主要针对问题。 （3）做好Code Review 记录。主要需要记录时间、问题的位置、问题的修改方案。根据团队自身情况，可以扩展记录的内容。记录的形式可以使用Confluence，也可以选择直接在问题除添加Todo。 （4）Code Review时除了发现问题，还会遇到写的好的代码，也需要及时的赞美，同时传播一些编程技巧和工具。

除去以上内容，在实际工作中，发现一个编程能力不足的团队进行团队Code Review能够帮助团队解决一部分问题，但是很多Code Review的结果不能就是纠正。也就是做了，但是不改。所以针对特殊情况特殊处理，在今年的一个项目上，采用1对1Code Review的方式，Review代码的时候除了说明是什么问题，为什么，还会当场进行修改。进行2周后，团队代码就有很明显的提升。

张维

熊节:极限追问032

【代码评审（code review）怎么做？】

背景:代码评审似乎是大家都愿意接受的良好实践，用不大的投入能对质量产生较大的提升。请大家分享一些做代码评审的经验。

分问题1:你的团队在什么时候做代码评审？

合并到主干之前进行代码评审。

分问题2:哪些代码需要被评审？

核心业务逻辑代码或者核心业务板块

分问题3:谁来做评审？

投影，大家一起看

分问题4:评审哪些内容？

重复代码，代码的命名，行为代码等

分问题5:评审过程中发现问题怎么办？

记录问题，下次接着讨论，确定方案后进行修改。

Paige

【代码评审（code review）怎么做？】

背景:代码评审似乎是大家都愿意接受的良好实践，用不大的投入能对质量产生较大的提升。请大家分享一些做代码评审的经验。

分问题1:你的团队在什么时候做代码评审？ —— 在Story编码自测完成后做

分问题2:哪些代码需要被评审？ —— 主要流程，开发者按业务逻辑讲述本次Story的编码，相当于带领大家来阅读Ta对需求的实现。

分问题3:谁来做评审？ —— 主要是团队内比较资深一点的开发人员。

分问题4:评审哪些内容？ —— 基本的代码逻辑，编码规范，业务理解（可能有些实现适合业务场景），潜在的隐患（比如缺少判空，可能导致抛出空指针异常）

分问题5:评审过程中发现问题怎么办？ —— 发现后，如果比较明显且没有争议，开发者记录下来，后续自行修改；如果有争议，大家讨论，最后得出结论后再修改；

这是之前就职的一家华为外包公司，所在项目采用了敏捷开发，参与过的代码检视。个人觉得确实是很有用的，旁观者清，就能比较客观地发现代码的问题，并且在讨论中能学习到别人的思路，对被检视人也是一种提升。现所在公司因为初创，进度很赶，没有单独组织代码检视环节，但我在开发中，如果遇到不太拿得准的，会找一两个同事做一下简单的检视。

马建勋

熊节:极限追问031

【代码评审（code review）怎么做？】

背景:代码评审似乎是大家都愿意接受的良好实践，用不大的投入能对质量产生较大的提升。请大家分享一些做代码评审的经验。

分问题1:你的团队在什么时候做代码评审？ 我们团队一般有code diff 和code review。 code diff 一般在大量重构或者比较复杂或者特殊逻辑实现的时候做。一般是写法吗的讲给组内其他人。 code review是在基于branch开始提交pr之后等有人review之后才merge。这时候的review第一是让别人检查自己的代码，第二高速团队自己了那些改动，一旦review过来拿代码就属于团队的，有什么问题不再是写代码的人的事情。

分问题2:哪些代码需要被评审？ 任何提交的代码或者说明。

分问题3:谁来做评审？ 组内的所有人除了代码的提供者。一是检查，第二相互学习。

分问题4:评审哪些内容？ 所有提交内容

分问题5:评审过程中发现问题怎么办？ 当场讨论，出范围的新建卡，范围内的商量达成一致后再修改在提交再审核

陈旭

【代码评审（code review）怎么做？】

背景:代码评审似乎是大家都愿意接受的良好实践，用不大的投入能对质量产生较大的提升。请大家分享一些做代码评审的经验。

分问题1:你的团队在什么时候做代码评审？ PR review 分问题2:哪些代码需要被评审？ 所有PR 分问题3:谁来做评审？ 同事互审 分问题4:评审哪些内容？ demo,代码质量，测试是否合理，设计是否合理。 分问题5:评审过程中发现问题怎么办？ 根据评审意见讨论改进代码，PR Review不通过无法合并代码。