每个人的代码风格不同，在需要团队协作的项目里，如果没有统一的编程规范，那么会出现各式各样的代码，这对于团队成员来讲是个「灾难」。在需要对接协作模块时，要花费大量的时间去阅读代码，如果注释写的不明确，那么耗费的时间和精力就更多。因此，没有代码评审的项目注定会变得难以管理，尤其是大型项目中，没有代码评审或统一的编程规范行为是无法想象的。
代码评审为代码质量和风格的把关树立了一道屏障，能够保证团队整体的代码风格的一致性，提前发现代码质量问题和编程中可能存在的问题，防微杜渐，保证合入分支的代码是得到团队认可的。
概念
「代码评审」是指通过阅读代码来检查代码的规范性和准确性，是保证代码质量的手段。
检查内容
代码评审的检查内容根据语言的不同，侧重点有所不同。以JavaScript为例：
- 命名规范：比如变量要采用camalCase的命名方式，类的命名则需要遵守PascalCase规则
- 缩进规范：代码换行以4个空格为单位，if…else, switch…case等关键字后要空一格，表达式结尾要有一个分号
- 代码结构：使用超过两次的代码视为重复代码，应当提取为公共代码；单个方法行数过长(比如超过了200行)；一行代码的最大长度为120，超过应折行；
- 第三方库的引用：长期没有维护的库或已知有明显bug的库不应引用到项目中
- 质量问题：异常处理不规范、代码存在安全性问题、可读性差、扩展性低等
以上内容在代码评审的阶段被发现，能够在项目早期将缺陷问题指出来及早指正以降低损失、提高代码质量、在评审过程中的探讨有利于拓宽思路，加深评审双方对项目功能的理解、促进团队沟通，对个人和团队都是双赢的。
快速通过代码评审的秘诀
首先评审双方应该明白代码评审不是针对某个人，服务对象是代码，目的就是发现代码中可能存在的问题及时纠正，双方都要带着批判的态度去审查代码，「对代码不对人」，要注意方式方法。
合理使用注释
代码注释用于辅助程序阅读，方便程序员可以不用运行代码就可以快速理解代码作用，也方便日后查看。注释中一般需要包括作者、邮箱、内容这几个主要方面。
注释对代码起到补充说明的作用，在必要的地方可以使用注释，但是有一点要注意，注释不是万能的，滥用反而会起到反作用。
仔细斟酌变量/方法命名
一个合理的命名对理解代码起到很好的先入为主的作用。名字能告诉你它要做什么，能够很直观地表达代码意图，有利于理解代码。因此不要害怕在起名问题上浪费时间，花时间起一个合理的名字会比将时间用于区分大量不合理命名的方法和类上更有效率。
有效的提交信息
一段好的代码应该是可理解的，变量/方法的命名应仔细斟酌，尽管注释能提供上下文，但这并不充分。还要注意以下几点：
1.提交消息
使用git提交代码时需要填写一行提交信息，用于描述本次提交涉及的修改内容。可以用简洁的提交描述，如果有需要进一步说明的问题，就需要在 commit message的body中进行补充。
提交消息的描述有助于评审人员快速了解本次提交内容，对接下来的代码评审有个大概的了解。
2.Bug报告
若提交是Bug修复，那最好在提交信息中关联Bug报告，有助于评审人员快速定位到问题，对代码实现逻辑和缺陷进行审查。
重新评估代码
代码提交之后不要立即发送评审，先自己对比一下，重新思考一下代码的设计是否有可以改进的地方、代码中是否还有拿捏不准的地方，针对评审人给出的意见给出回答，同时思考一下是否可以改进代码，使其更加合理或易于理解
如何做好代码评审
评审前提
能为他人做代码评审的前提是评审人对团队规范是熟知的，在以往编程中践行着规范，所以才能指导他人。因此由于评审双方背景、能力、对功能点理解等方面的不一致性，需要沟通提问来加强理解。
有效评审
有礼貌的提出评审意见，关注点放在代码，而不是「人」上，会更加有利于对方接收自己发出的信号；相反，生硬、严厉、贬低的词汇不利于对方改进代码。
有效反馈
对不同重要程度的代码问题，要指明优先级，比如必须改正的、可选的，因为有些逻辑缺陷等有重大影响的问题是一定要修复的，属于各人不同编程风格的问题也不一定强求统一。
最后
最近找到一个VUE的文档，它将VUE的各个知识点进行了总结，整理成了《Vue 开发必须知道的36个技巧》。内容比较详实，对各个知识点的讲解也十分到位。
有需要的小伙伴，可以点击下方卡片领取，无偿分享
