本文转载自微信公众号《微信大学前端技术》，作者张宇航。转载本文请联系微一大学前端技术公众号。前言没有无缘无故的爱，没有无缘无故的恨，当然也没有无缘无故的codereview。为什么CR要给你讲故事？没有评论，什么都没有，如此明显的错误。当时全班都不敢说话，慌得要死，生怕是我在说话。领导说：“大神A”查看提交记录，谁提交了就请你吃饭。两分钟后，“大神A”：这个，这个是我自己一年前提交的。所以不想给自己丢脸，赶快复习代码吧。1.角色功能作者为需求开发者。要求：注意评论。复杂的业务写相应的注释，commit中写具体的提交背景，便于reviewer理解。以正确的态度接受别人的评价。不要与审稿人给出的意见相矛盾。你可以委婉地拒绝你认为不合理的建议，或者详细说明你的观点和理由。审稿人的意见不一定合理，审稿也是一个相互学习的过程。评论修改完成后及时反馈。Commit提交信息备注如“reivew:xxxx”，保证复检效率。作为cr参与者，reviewer推荐由项目负责人和项目参与者组成。要求：指定评论类。reviewer在对相应的代码段进行评估时，需要注明相应的级别，比如fix:xxxxxxx其中修改是强制性的，并提供修改建议advise:xxxxxxx其中修改是主观推荐的，不是强制性的，并且可以提供修改建议问题：xxxxxxexistshere有疑问需要作者做出解释和友好的评论。注意评价的措辞，可以说“我们如何调整和修改它，它可能更合适......”，为了更好的代码，我们也应该给予足够的好评。享受评论。切忌抱着吹毛求疵的心态复习。一个好的审稿人不是通过提出问题的数量来衡量的。跳出自己的编码风格，主动去理解作者的思路，也是一个很好的学习过程。二、CR流程1、自检commit前，要求diff检查文件变化，可以用gitk完成。当然，如果项目使用了pre-commit关联的lint校验，也可以查到debugger、console.log等语句。不过还是建议大家在每次投稿前先检查一下投稿文件。在多人协作下提交。多人协作下的分支合并请求时，需要注意是否带入了不必要的commitcommit消息。建议连接husky、commitlint/cli和commitlint/config-conventional验证提交信息。commitlint/config-conventional提供的类型有feat：新特性修复：bug修改chore：优化，如项目结构、依赖安装更新等docs：文档更改style：样式相关修改refactor：项目重构进一步增加incommitmessage信息量有助于reviewer和他们自己更有效地理解commit内容。2.CR测试时发起CR，要求的任务与reviewer关联。提供合并请求，配合gitlab/sourcetree/vscodegitlens等工具。审稿人完成后，反馈审稿人的建议并修改，commitmessage会提示类似'reviewfix'的信息，方便审稿人复查。急需，特殊事项，略过cr链接，事后复习。3.CR标准不纠结编码风格。编码风格交给eslint/tslint/stylelint代码性能。大数据处理、重复渲染等代码注释字段注释、文档注释等代码可读性。过多的嵌套、低效的冗余代码、功能独立性、可读变量方法命名等。代码可扩展性。功能方法设计是否合理，模块拆分等。控制审稿时间成本。审阅者尽量由项目负责人组成，关注代码的逻辑，不需要逐字逐句地理解。4.最后，总体来说，cr并不是一个找bug挑错的过程，不会降低整体的开发效率。其目的是保证项目的标准化，让其他开发者在扩展和维护项目时节省更多的时间和精力。当然，cr链接需要团队的每个成员都去推广。只有大家认同和参与，才能发挥出cr的最大价值。图文末，安利用gitlabbranchreview开发的一个vscode小插件。主要流程是点击按钮发起合并请求，自动生成mr链接，发送到企业微信通知相关负责人开始审核。
