本来想写一篇关于 Code Review 的文章，后来写着写就发现，这里面的故事很多，文章里尝试提出一个新 Review 方式，仅供大家参考。
Code Review 你们做吗？
在知乎搜了一下，看到下面这句话：
不要去不做 CodeView 和 单测 的公司
Code Review 好处多多，不需要更多的篇幅来说 Code Review 有多么有必要了，问题主要是多数公司团队在很难做好 Code Review ,也包括我所在的团队。
做不好 Code Review，大致有以下几个因素：
- 时间紧张，排期很紧，业务催得紧，
Code Review太浪费时间 - 需求变更频繁，都疲于应付需求
- 团队意识不到位，工程化思想不足，懒得做
- 自己写的未必就好，也没办法给同事意见，技术储备不足
别人家是怎么做 Code Review 的 ?
大体上有两个做法：
- 定期开
Review会，日级别或者周级别的会议 - 和
Git开发流集成，提交 PR/MR 时指定同事Review，检查通过后才能合并代码
这两种做法都是经典的做法，同时出现了很多的辅助工具，其中有代表性有下面两款：
- Phabricator： Facebook 的作品，基于 PHP、MySQL ，功能完善，支持多种代码仓库，有社交属性，这和 Facebook 的基因相匹配，提供了
Review和Audit两种模式，Review模式采用pre-publish，Audit模式采用post-publish，可以参考文章 Review vs Audit - Gerrit：Google 的作品，也是很成熟的系统
- GitHub或者GitLab，支持
Pull Request或Merge Request，基本满足需要，不过这两系统的重心不是Code Review
上面的列表中，我只是用过最后一个，其他的只是看过介绍，不好评价，看起来大家更倾向于 Phabricator，而文章中提到 Audit 模式，也是我下面倾向的方式，只是稍有些不同。
下面说下我的想法。
同步和异步
签入之前提进行 Review，或者开会进行 Review，都是同步的过程，需要当事人在线或者在一起才行，这种方式是比较消耗时间的,代码审核粒度比较大，功能已经基本测试完成，审查出问题，需要开发修改，开发也不想改，因为木已成舟，改起来，还可能有风险，影响上线。PR/MR 也可以粒度小一些，不过对双方来说，还是会浪费时间，最后就是走个过场。
如果采用异步审查，每天审查一次，每次粒度不会太大，审查不会花费太多时间，刷个朋友圈的时间，代码就看完了，多数代码没问题就过了，偶尔问题，及时提出来，当天就可以修正。
想起来，同步变异步，是现实世界一直存在的过程：
- 以前都是打电话，现在发微信
- 以前商场购物，现在网购
- 以前到点了才能看到电视节目，现在随时可以
- 以前打车必须站在大街上，现在用滴滴
- 以前必须起早去医院挂号，现在有114预约，自助机取号
看起来，整个世界，都在向异步的方向发展，所以代码审查，是不是也可以异步？
文化的形成
说到文化的形成，这个应该是某个文化大咖的论题，我就是简单说说我的看法，为后续内容铺路。
先说我的想法：
文化必须要有对应的环境、载体和受众
比如：
- 有了互联网以后，出现网购文化，上来就是一个：亲～
- 有了微博，朋友圈，出现点赞的文化，不点个赞见面都尴尬
- 有了抖音和快手，就有了短视频、直播文化，老铁双击666
- 传统的京剧，没了环境、舞台和受众，要再度流行，必须要现代音乐的包装，比如中国风的音乐
上面的例子应该还有很多，不过我不是搞文化的，不多说啦
我想说的是，我们需要基于我们所处的环境，利用一个载体来推动文化的形成。
我们的环境是什么？
产品迭代很快，一个新产品，从想法到第一个版本上线，也就两三个月，运营半年，不行就下线
互联网时代，这种现象很常见，大公司每年失败的产品非常多，对公司来说多尝试新的产品，模式是好事，但是对程序员来说，疲于奔命，没人关心的你的技术成长，做好 Code Review，是团队技术成长的一个好习惯，但是在这样的环境下，怎么做 Code Review 呢？
比如微软，IBM，Google,Facebook等公司，对软件质量、安全、性能等等要求很高，因为他们的产品受众广，运行环境很复杂，必须要提交前审查，还要做单测。
大型互联网公司的中台，产品稳定，为业务团队提供保障，对质量，稳定要求很高，可以很好的做单测和前置的 Code Review。
Review vs Audit 文中很推荐 Review 模式
If you aren't interested in review, just do audits. You can always change your mind later. But consider review! It's really good, we promise!
我们和他们的不同，在是在环境上的不同，所以如果真要照搬他们的做法，你会觉得不适应，太教条，最后从入门到放弃。
我们必须基于现状去思考解决办法，而不是生搬硬套，所以，基于我们面对的环境，我们需要有一个新的载体来帮助我们形成文化。
这个新的载体就是我要说的 Daily Review 系统。
构建 Daily Review 系统
前面花了很多篇幅讲了这个系统的的背景，主要是希望在我们面对的环境下提出一个解决方案，如果你们团队也有类似的环境，或许这个系统也适合你们的团队，下面主要说下这个系统的设计思路。
Commit流，系统将每人每天的代码合并到一个Commit，每人也可以利用Rebase命令优化自己的Commit，方便浏览。- 以人作为纬度显示
Commit流，而不是以系统，用户可以选择某人进行关注，只显示我关注的人的Commit流。 - 任务驱动，每一个
Commit作为一个代办任务，每日清理自己的代办任务，对Commit提交修改建议，也可以讨论优化方案，确定后，作为一个优化任务发给代码提交人。 - 可以点赞，对好的代码表示鼓励。
- 系统基于
Git，但是不严格要求并入开发流，也就是用异步而不是同步的方式做Review。 - 支持移动端，方便低头族，上班路上也可以。
以上是对这个系统的简要说明，回头来看，这不就是一个知乎或者微博系统吗？没错，真就是
那么这样一个系统能带来什么好处呢？
Code Review分散到每一天，每人每天写的代码花十分钟大致浏览完，有问题就及时提出来，当天就可以修正，不至于等提PR/MR或者开Code Review会议再提出来，然后被问：你为什么不早说？- 想关注谁的代码都可以，你可以专注大佬的代码，未必要
Review他的代码，就是看看大佬每天写什么，多学习学习，或者关注同事的代码，看看Review记录，避免犯同样的错误。 - 领导可以关注下新员工，看看每天都写了什么代码，
Code Review做得怎样？看看最近有没有进步？项目进度怎样？监控你每天写的代码，这招狠不？当然，领导也可以在gitlab上查看你的代码，就是有点儿麻烦 - 对开发者来说，想到第二天有人看自己的代码，也会比较慎重思考自己的代码，或许会请教下同事，类似的需求怎么实现最好？同时也会完善注释，毕竟我的代码是给人看的。
- 沉淀知识，针对好的
Code Review可以作为最佳实践，新员工可以浏览，减少后续Review的成本 - 包括其他所有
Code Review所带来的好处
好了，这就我臆想中的 Daily Review 系统，不知道您觉得怎样？
我相信，即便是传统的软件公司，已经把 Code Review 做得很好的公司，也可能希望有这样的系统。
好啦，每天上班，从处理 Review 任务开始，无聊的时候，可以刷刷 Review 系统，排队的时候，可以相互看看代码，不懂的交流一下，这就是文化。
不过，还是有点担心，毕竟刷朋友圈，刷抖音会比较愉快，刷 Review 系统，可能会不那么愉快，这可能是一个问题，不过保持一个透明的文化，利于成长的文化，有更多人关注你，给你提出好的建议，这不是一件令人开心的事吗？
其他问题：
- 代码提交前利用
Lint工具进行检查，ESLint，TSLint等，检查通过再提交，避免格式问题和低级别语法错误 - 设计的
Review，最好开工前先描述下设计，相关目录加一个Readme文档，作为一个Commit提交 Commit格式规范，方便提取信息，参考commitizenPhabricator的Audit模式也是可以试试
最后
本文尝试提出一个新的 Code Review 方式，简而言之，用类似微博，知乎这样的系统做 Code Review，并且试图让 Code Review 成为一种文化，关于同步异步和文化的形成部分都是 yy，没有参考 CCTV，文章写了好久，不当的地方请指正，希望大家能有收获。
下次，碰到大佬你可以说：Can I follow your code ?
参考阅读：
