Code Review 的经验
为什么进行评审
- 首要目标：促进工程师日常代码交流和人员的成长上面来，提高开发者自身水平。
- 次要目标：找出并修正软件开发过程中出现的错误，保证软件质量。
好处
- 短期内迅速提高代码质量
- 大家知道自己的代码会被人审核之后写得会比较认真
- 理论上代码质量是由整个团队内最优秀的那个人决定的
- 在 Review 的过程中学习到其它同事优秀的编码
- Bug 数量迅速减少
- 团队成员对项目的熟悉程度会比较均衡
- 新同事通过参与 Code Review 能很快熟悉团队的规范
- 对公司来说避免了人员的风险，对个人来说比较轻松（谁都能来帮你），可以选自己喜欢的任务做
- 改善团队的氛围
- 无论级别高低，大家的代码都是要经过 Review 的，可以在团队内营造一个平等的氛围
如何进行评审
1. 从点赞开始 👍
被 Review 的 PR 可能有很多显而易见的错误：误用了错误的 HTML 元素；实现与最初的原型和设计不符；逻辑代码没有意义等等。
评审员的工作就是找到这些错误并纠正，但是没人是故意犯错，公开指出错误会令人不舒服，即便你以为自己是对事不对人，但对被评审者来说往往不是这么回事。
为了给本次评审定一个积极的基调，我的经验是先从肯定别人做的好的部分开始。即使代码中有很多问题，我们也要先肯定他的贡献。错误的代码好过没有代码，感谢他们在解决这个问题上迈出了第一步。
就算真的挑不出这次 PR 中的亮点，也要想办法赞扬，这有助于让被评审者建立信心，更容易接受接下来的反馈。也许逻辑写的不好，但是他们做的很好（至少完了交给他们的任务）。
2. 用 “代码” 代替 “你”
如果你看过一些语言沟通艺术方面的书，你大概知道这招：不要说有针对性的词语，多说 “我觉得”，“我想”，而不说 “你”，“你这块”。将谈话的焦点从针对人，转移到针对问题本身。
要知道让人接受批评已经很难了，注意点你自己的说法方式，小心挨揍。所以在 Code Review 的时候绝对不要说 “你” 不要让别人觉得是他们错了。
错误：
Your logic on line #25 isn’t clear.
正确：
The logic on line #25 isn’t clear to me.
3. 对特定的代码行进行评论
Github 或者 阿里云都有这个功能，就不赘述了。在 PR 的某一行下面直接添加评论，这样容易改，也可以很方便积累成 TODO list。
4. 尽早设置项目标准和引入自动化 Code Review 工具
每个人的编写代码的方式和风格都不同，所以应该尽早确定团队的代码风格、命名约定、项目组织等规范。无论你的标准是什么，重要的是整个团队都坚持使用它。
常见的项目规范包括：语言规范；Git 工作流；项目组织规范；注释约定。
每当有新员工入职的时候，可以带着他一起参加 Code Review，通过在 Review 的过程中提出
Code Review Tool
就是 Linter 那一套，不差钱的话网上也有很多相关的服务，可以引入到 CI 流程中。
5. 先大体再细节
- 有没有失败的测试，为啥测试挂了
- 代码库中有没有不应该存在的文件
- 我能否检出该分支代码，并直接运行
- 如果第 3 步需要额外配置，是否在哪里说明了这些变化
- 项目中是否添加了新的包和依赖？为什么要添加它们？必须吗？
- HTML 相关的检测，比如 valid, semantic, and accessible
- CSS 是否遵守了项目规范，是否考虑到了浏览器兼容，自适应布局等
- JS 代码是否遵守了规范，模块化了吗，逻辑容易懂吗，边缘条件是否考虑到，控制台中是否有日志
这些简单的步骤先做完，之后再去评审代码的细节逻辑部分。
6. 抽出专门的时间进行评审
开发团队不能为了进度牺牲质量。
即便你很忙，也不要抽零散的时间进行评审。要和团队一起规划固定的时间进行代码评审。大家都知道周几会进行代码评审，并做好准备（嗯，我的垃圾代码要在那天之前重构，测试要修好，文档要补全）。
如果开发任务真的特别紧，Code Review 也一定会做，所有的问题一定会被提出，只是会根据进度的紧迫程度，以及问题的大小，改动成本，决定问题是现在解决，还是加一个TODO，并记录在缺陷跟踪管理系统内，以防日后遗忘。
7. 建立目标和期望
考虑一下问题：
- 是否应该将 PR 和 issue 关联起来
- PR 是否需要遵循某种格式
- 对一个 PR 中包含多少代码应该有限制吗
如果你的答案是肯定的，那么提前建立这些规范很重要。既节省了你的时间，你的团队也不需要猜测你的期望。
注意，这种事情不要独断专行，大家一起讨论一个都认可的方案。
8. 互相 Review
即便你是你们团队中的 Leader 并且经验超过其他人 5 年，你的代码也要被其它人评审。
- 你的代码可能存在错误，并可改进
- 其它初级程序员，可以在你的代码中学到东西
阅读优秀的源码始终是程序员进步的一个较好方式。
9. 经常 Code Review
代码评审是一个很好的学习过程，可以考虑把它归入 sprint 之后的固定流程。和队员一起发现问题，哪些点评有帮助，哪些没有帮助，并将经常出现的问题通过自动化工具解决掉。
10. 有不止一种解决方案
切忌要避免过犹不及。当你开始评审的时候，有时候会不由自主的帮忙去重构别人的代码，最终往往演变成你按照自己认为正确的想法把整个功能重做了一遍。这不是 Code Review 的目标！
的确，有时候我们不得不在审查之后重构代码，但这不应该是一个频发事件，如果你发现经常陷入这种状态，那你要做的应该是和对方结对编程，一起来实现这个功能，而不是在功能开发完成之后重写。
记住，每次进入会议室开始进行 Code Review 之前，先提醒自己，这对大家包括你来说是一次学习的过程，而不是让你炫耀自己技术的机会。
