前端代码规范（1）谈code review_前端code review

一、review代码的认知

1、code review目的

• 保证代码可读性，一致性
• 代码层面减少bug，最基本缺少控制判断、异常处理
• 传播知识+设计讨论。

相信很多人第一次提交 Code Review 都有类似的经历：短短几百行代码，却被提了密密麻麻几十条 comments，更新了十多次代码，才最终被 accept 。其实当代码被 accept，提交代码的工程师通过这次 review 就学习到了代码规范和很多好的实践。同时，通过 review 更资深工程师的代码，年轻的工程师也更直观地学习架构和编码；另外，工程师之间也可以通过 review 代码来共享项目知识，看代码实现在绝大多数时候是了解项目的最好方式。

以下总结最本质的目的

cr实际上是为了在不同人员的交流中进一步完善优化产品代码架构，也是为了减少无效交流，提高沟通效率的做法。

cr核心不是发现bug（这应该靠单元测试），而是提出“这样做技术上没错，但是思路和扩展性上存在问题”这类改进意见。

2、利弊权衡

2.1、优点：

其实上面的目的已经很清楚列出来了，除此之外根据实际体验，还会有感觉到一个大项目逻辑层面bug从5-10个降低到2-3个的水平，就算review没有指出bug，但是自己按照review优化代码时很容易发现潜在问题。review​后减少测试bug是实实在在能体现出来的效果。

• 提高可读性
• 减少bug
• 提高代码架构设计（方便维护）
• 减少重复代码（有些项目新手很容易多个轮子），比如日期处理函数，common有。自己页面也写，utils有，service也有。导致多处重复。

2.2、目前遇到的问题：

Review代码之前团队没有，也很羡慕有这个机制的团队，可以提升代码质量促进个人成长。后来加入一团队Review code  要求很高的团队  发现好多问题。

（1）开发三天代码，review+自己修改，修改完再review  基本需要半天-一天来完成代码review，哪个主管愿意这么搞？ 很多人都是2天开发2天review

（2）同行或者上级对代码修改建议完全按照自己的标准，或者每个人都有自己标准，比如一个函数可能有一种写法，review非要你换种写法，其实两种写法差别不大。就像leetcode  一个题有很多解法，很难说某一种写法就是最优解。我就经历过一个15行函数为了改成10行被要求反复改一下午

（3）原有的代码结构被review的人要求改结构往往改出很多新bug

国内很多团队为了review而review。review过程成了领导瞎指挥找存在感的途径

案例吐槽

（1）A是我的前辈，一次三天开发周期的工作其中用到他去年开发的一个功能模块，我直接移植过来使用。找他review代码时，让我把这个他之前写的代码全重构一下，说只要是出现在我代码中就算我的 。也就是我项目中有他代码模块，他review觉得很垃圾让我改掉，但是问题是我就分配三天开发周期，重构需要增加1-2天工作量，且这个功能线上是没问题的，我重构可以，但是其中 增加的重构时间和测试成本全算我身上。

（2）实属领导没事找点事做，显得工作忙（其实直接merge），忽弄一下新手差不多，再说业务细节都不清楚，review毛的代码！检查语法错误那是机器的事，不是领导显摆的地方！方案是否合理是code之前该讨论确定的，更不需要马后炮。

（3）

领导：“我觉得你这段代码组织不好，你回去重新组织下”

我：“请问哪里不好，我回去改”

领导：“我也不清楚，你自己慢慢改，反正说不上来，就是不太舒服”

我：“。。。”

3、应该在哪个阶段

有些团队里 Code Review 处于开发流程的边缘位置，有些团队 Code Review 处于代码编写到部署的必经部分。对于我们来说，Code Review 是代码编写到部署的必经部分，所有代码都必须经过 Review 才能 merge。

目前我认为最好的阶段是，开发完成后，与产品和测试完成桌面检查后进行。

因为我们经常会出现开发完成，review完，产品和测试进行验收时各种需求调整（稍微大点项目100%）

需求调整就意味着代码调整，你之前话很长事件优化的代码很可能毫无作用。桌面检查意味着需求完全固定和确定

当然针对一些核心大项目，在review时发现架构设计并不合理，此时再修改会浪费大量时间。所以这里建议，涉及大型架构涉及的代码，最好在开发时期就相互沟通交流。不要出现自己闭门设计3-5天，开发基本完成review时发现设计有很大问题，面临被要求重构的地步

至于项目太大可以进行分阶段分模块进行reciew

4、什么样的团队需要代码review

如果你的团队需求并不多，那最好情况当然是所有产出代码都需要review。但是996的现实，让我们不得不做一些取舍。

• 技术驱动型团队：一般涉及系统底层逻辑较多，功能路径难以被测试覆盖，而产品质量问题很多时候是致命的，所以这样的团队更多需要开发编码的严谨性和相关代码质量的保证活动。手机管家高权限应用组就属于这一类型。
  
• 公共服务型团队：一般服务于多个团队，一旦出现质量问题影响范围会比较广，所以除了在测试方面加以把关外，通过CodeReview活动来提升开发质量是非常有必要的。
  
• 测试缺失型团队：这样的团队由于缺乏测试环节，质量问题带到线上的风险会很高，强烈建议在开发环节做好自检工作。
  
• 新人密集型团队：新人的代码可读性往往是比较差的，特别需要组织能及时给予纠正，帮助新人养成良好的编码习惯。同时如果团队产出的代码可读性较高时，新人也可以更快上手工作。
  
• 任何有主观意愿的团队：这样的团队或领导者认同CodeReview的意义，或团队成员对代码质量提升有追求。
• 长周期迭代维护团队：有些软件初次上线后需要长时间的迭代，没法保证每次都是一个人迭代，软件周期中可能开发人员换了一波又一波，这时候每次开发的代码规范显得尤为重要。

5、什么样的团队不需要代码review

• 不认同型团队：即领导和团队骨干都不认同CodeReview意义的团队，这样的团队无论从推动还是坚持上都有很大挑战。
  
• 疲于应付型团队：这种团队一般没有建立必要的持续提升机制，每天淹没在各种需求沟通实现变更和优化中，自然，代码质量提升活动也很难被列入backlog。常见的996，007都无法完成需求开发，你还要加个review？
• 创新型团队：这种团队的重要任务是要把产品快速推向市场进行价值验证，所以在代码编写上要求足够敏捷，代码暂时的混乱完全可以接受。
• 快速量化团队：国内很多团队，类似活动页，功能页，一次上线可能一个月就下线，或数年不更改代码

二、CodeReview 入门

6、如何有效开展CodeReview活动？

6.1、代码规范：明确Coding规则

如果一开始不定义好团队Coding标准，那在检视过程中就会存在两种情况：一种是各种不同的意见很难快速达成一致，影响review效率，另外一种是团队根本就不会重视代码规范的检视， 如果是前者还好，毕竟大家都还在关注什么写法是好的或对的这个问题，只要中途愿意建立起Coding规则，问题就能很快解决。而笔者跟进过的一个团队恰恰就出现了后者的情况：该团队由于前期没有明确Coding规则， 过程中大部分开发人员对规范类问题直接无视，CodeReview运作一段时间后代码中依然存在命名不规范，可读性较差等问题，直接影响了活动效果，这是我们非常不愿意看到的。

如果发现代码至少2出不符合既定规范（缩紧不对，明明不是驼峰，事件不是handle开头等）可直接打回，自己review后再提交给别人review

6.2、检视指南：消除困惑和迷茫

检视指南又名CodeReview-checklist。一个团队并不是所有人都是老司机，有很多同学是没有代码review经验的，他们往往不知道应该重点 check哪些点。

这个时候结合自身业务特点和团队之前踩过的坑，制定一个checklist是非常必要的:

• 什么写法可能导致性能低下？
• 哪个接口要慎用？
• 哪些设计方式需要规避？
• 什么习惯容易引发内存泄漏？
• 函数尽可能在10行以内
• 相互依赖的promise合并起来使用promise.all
• 所有事件前缀使用handle
• 变量和函数明明必须规范
• 等等。。。

这样可以让经验不足者在不知道要review什么时，能有的放矢，过程中逐步积累起经验

当然也有人说，我的团队代码检视都是让资深骨干做的，不存在不知道怎么review的情况。

但是我想说，骨干员工的时间毕竟很宝贵，他们也往往很忙碌，为什么不让更多的成员一起来参与review工作呢，毕竟CodeReview不仅仅是找茬，也是代码的交流和学习！

针对实习生最好让1-2年经验的先review一遍做初步过滤

6.3、总结优化：透明问题，持续优化（非常重要）

我们看到很多团队的CodeReview活动坚持不下来或逐步流于形式，其实最主要原因是过程中缺乏定期回顾和总结，从而不知道如何有效促进和帮助团队更好运作。

为了更好地促进这项活动，手机管家高权限应用组就专门成立了CodeReview组委会，这个组织每月都会对CodeReview运作状况进行总结，分析问题，解决问题，持续优化，其最后的效果能在团队内外均获得较高的认同度，可以说总结优化这个环节起到了非常关键的作用。

6.4、激励机制：激发主观能动性

由于CodeReview本身跟人的经验或者意识都有很大关系，很多时候我们会为调动不起开发同学的积极性而烦恼，所以为了让大家更好的参与这个活动，我们一般都需要制定相应的激励机制。也有人说了，如果是leader强制跟考核挂钩，那就不需要这个东东了，嗯，但换个角度看，跟考核挂钩难道不是另外一种“激励”方式吗？哈哈。。。

对于高一级别的开发者，review代码平均至少要占有起1/5的时间，最好的方式就是将其算入工作时间内。且review 之后的测试将代码问题bug归类进行统计。一次设立奖励机制。

6.5、对评论进行分级

在做Code Review时，需要针对审查出有问题的代码行添加评论，如果只是评论，有时候对于被审查者比较难甄别评论所代表的含义，是不是必须要修改。

建议可以对Review的评论进行分级，不同级别的结果可以打上不同的Tag，比如说：

• [blocker]: 在评论前面加上一个[blocker]标记，表示这个代码行的问题必须要修改
• [optional]：在评论前面加上一个[optional]标记，表示这个代码行的问题可改可不改
• [question]：在评论前面加上一个[question]标记，表示对这个代码行不理解，有问题需要问，被审查者需要针对问题进行回复澄清 

类似这样的分级可以帮助被审查者直观了解Review结果，提高Review效率。

7、review代码操作规范

1、对事不对人。大家是同事，在一个团队工作和气很重要。不要在 Code Review 中说“你写的什么垃圾东西这种话”，你可以说“这个变量名不好理解，咱们换成巴拉巴拉是不是更好”。

2. 每个 Review 至少给一条正面评价。Code Review 本意是改善代码质量，增强团队成员之间的沟通，但是我一提交代码就有人说我写的垃圾，这很打击自信心啊，也不利于团队成员和平相处。代码有问题，指出问题是必须的，要实事求是，但是有的时候也需要给队友一点鼓励，例如简单的 或者“赞一个”我都很开心了

3. 保证发布的代码和评审意见的可读性。大家都是程序员，你提交代码的时候，在符合团队风格的同时，把代码弄的好看点，如果你明确自己这个代码哪个地方不足，Highlight 出来让大家给意见。如果你是来 Review 代码的，把意见写的通顺点，评论有条理一些。对反引号 (`) 嵌入代码或三个反引号 (```) 写代码块，这样看的舒服得多，效率也高。

4. 用工具进行基础问题的自动化检查。用 Tab 还是空格，用两个空格还是四个空格，函数后面怎么换行等基础问题检查，可以使用 eslint 和Rubocop 等类似的工具进行，团队成员应该把更多精力放在代码规范，代码性能优化等地方。

5. 全员参加 Code Review，并设定各部分负责人。扩大 Code Review 参与面，参与不是说一定去审核别人的代码，可以是代码被审核，也可以是看别人审核意见，这都是学习的过程。并且每部分设定负责人，该负责人对这部分代码质量负责，负责人需要是资深工程师。全员参与 Code Review 可以让团队成员更快的成长，新人在看大佬 Review 代码的过程就能学到很多。

6. 每个代码 PR 内容一定要少。Code Review 效果和质量与 PR 代码量成反比，你一下提交这么多代码，我今天还下不下班了？ 我女朋友你帮我陪？每次 PR 代码量小一些，看起来速度快，又不至于失去耐心，这样才能达到 Code Review 的效果，所以要经常进行 Code Review，但是每个 PR 代码量要少。我建议要少于 300 行/PR。

7. 在写新代码之前，先 Review 掉需要评审的代码。你让我去 Review 一周前的代码？我还得把思维和项目进度切换到一周前？大家肯定不愿意，所以要形成规定，写新代码之前先把旧的 Review 掉，提交 PR 的时候也保证代码量小，这样 Review 起来不需要大块时间，改起来也快。不能因为 Code Review 大幅耽误项目进度，进度是全团队的事，不是某个人的事。

8. 如果你有更好的方案，尽管提出来。在 Code Review 中经常会发现写的不好的地方，如果你有更好的方法，欢迎提出来！首先能改进这个 PR 的代码，其次能体现你的能力，团队应该定期对这种提出好的解决方案的同事进行奖励。

9. 不要在 review 中讨论需求，review 就是 review。不要在 Code Review 里搞别的，有需要就另安排时间进行，要明确 Code Review 是完善代码，不是需求和功能讨论，始终要以代码质量为中心。

10.意见必须明确，不要出现我觉得你写的不好，但是怎么改进我也不知道。要不不要给意见，要不就要给清晰的意见。

三、怎么配合review

8、配合开发流程？

像Github Flow这样基于分支开发的流程是特别适合搭配Code Review的。其实不管什么样的开发流程，关键点在于代码合并到master（主干）之前，要先做Code Review。

• 单人开发拉取一个分支对应一个issue
• 完成桌面检查之后进行review（保证开发符合要求和固定需求）
• 每次review 前需要把修改的代码进行rebase合并成一次commit
• 修改代码之后review通过后再rebase一次进行提交测试请求合并
• 第一次完全测试完，再进行bug修复
• bug修复完进行rebase和代码review
• 第二次测试完重复以上。

9、真遇到紧急情况，来不及代码审查怎么办？ 

虽然原则上，必须要Code Review才能合并，但有时候确实会存在一些紧急情况，比如说线上故障补丁，而又没有其他人在线，那么这种情况下，最好是在任务管理系统中，创建一个Ticket，用来后续跟踪，确保后续补上Code Review，并对Code Review结果有后续的代码更新。

10、先设计再编码

有些新人发现自己的代码提交PR（Pull Request）后，会收到一堆的Code Review意见，必须要做大量的改动。这多半是因为在开始做之前，没有做好设计，做出来后才发现问题很多。 

建议在做一个新功能之前，写一个简单的设计文档，表达清楚自己的设计思路，找资深的先帮你做一下设计的审查，发现设计上的问题。设计上没问题了，再着手开发，那么到Review的时候，相对问题就会少很多。

11、代码提交前自己检查

我在做代码审查的时候，有时候会发现一些非常明显的问题，有些甚至自己都没有测试过，就等着别人Code Review和测试帮助发现问题。这种依赖心理无论是对自己还是对团队都是很不负责任的。 

一个好的开发人员，代码在提交Code Review之前，肯定是要自己先Review一遍，把该写的自动化测试代码写上，自己把基本的测试用例跑一遍的。

我对于团队提交的PR，有个要求就是要在PR的描述中增加截图或者录屏，就是为了通过截图或者录屏，确保提交PR的人自己是先测试过的。这也是一个有效的辅助手段。

12、PR要小 

每次review代码最好在300行以内（前端按照js计算最好在300以内）。至于项目太大可以进行分阶段分模块进行review。

13、Code Review 工具

推荐一些 Code Review 工具，可以了解一下：

• Crucible：Atlassian 内部代码审查工具；
• Gerrit：Google 开源的 git 代码审查工具；
• GitHub：程序员应该很熟悉了，上面的 "Pull Request" 在代码审查这里很好用；
• LGTM：可用于 GitHub 和 Bitbucket 的 PR 代码安全漏洞和代码质量审查辅助工具；
• Phabricator：Facebook 开源的 git/mercurial/svn 代码审查工具；
• PullRequest：GitHub pull requests 代码审查辅助工具；
• Pull Reminders：GitHub 上有 PR 需要你审核，该插件自动通过 Slack 提醒你；
• Reviewable：基于 GitHub pull requests 的代码审查辅助工具；
• Sider：GitHub 自动代码审查辅助工具；
• Upsource：JetBrain 内部部署的 git/mercurial/perforce/svn 代码审查工具。
• Review Assistant

参考

部分参考引用

大家的公司的 Code Review 都是怎么做的

大家的公司的 Code Review 都是怎么做的？遇到过哪些问题？ - 腾讯Bugly的回答 - 知乎

大家的公司的 Code Review 都是怎么做的？遇到过哪些问题？ - 程序员客栈的回答 - 知乎