前言

今天周五，浏览的东西有点多。
从百度 EFE 一直找到了 Code Review，中间还穿插了 trello 该如何更高效地使用这种问题。下面这段文字让我很有兴趣。
如下：

来源： 腾讯Bugly：分享一下鹅厂团队的Code Review经验
当然也有团队负责人说了，每天纠结于空格少了，行数字符多了等细节问题没意义啊，不想浪费这个时间，因此我们不需要代码规范。
我个人不认同这个观点，因为代码规范并不只包括空格和字符等约束纬度，还包括了注释的要求，命名的规范，命名是否词能达意，代码结构安排等等影响代码可读性的因素。
如若这些方面连基本规则都没有，那一定会出现之前说的那两种情况（争议太多 or 完全忽视），效果可想而知。所以你可以根据自己的看法或需求做一定的规则定制，但不能没有 Coding 规则。

我扪心自问了一下，发现自己还挺喜欢这种 review 和 严谨地要把中文括弧变成英文括弧、删除多余的空格；准确的注释、完美符合规范的精神。

当然后者比较重要，前者在不影响整体的时候，如果只是美观问题，其实是可以忍受的，后者就像是团队文档命名规范不统一，让整个目录乱七八糟，找不到文件。增加沟通成本、降低效率。

---

每次 review 都很有价值

我认为任何 review，无论是对成功事件的 review 还是对不成功事件的 review，都是除了“最有价值环节：克服大困难”之外的最有价值的环节。

它就像是任务后的经验加成药水，x2 bonus，x5 bonus，x10 bonus！如果不做，简直浪费了快速升级的机会。

虽然在工作中，不见得每次都会有人主动牵头 review，也可能项目太忙没时间深入探讨，但是我还有很多选择：

• 主动交流自己的体会和从这件事中得到的教训
• 及时记录下一两点想法，得空的时候完善它
• 如果是那种我觉得可能会很有价值的想法，熬夜搞定

---

各种各样的我

我挺羡慕那种脑子转得特别快，反应特别灵敏的人，我想他们可能不用我这样停下来去总结吧，但我知道我不是他们。

也有不少人觉得我反应很快，但其实只是这个问题，我恰好有过思考，或者我本身就有过比较深入的研究，这样就显得我挺厉害的样子……

真实的情况是，在大部分非必要的交流中，如果是我没有兴趣的，我根本就不会介入；而那些我会参与的交流，就表现得挺不错。这也难怪，我的朋友们对我的评价都差异挺大的。

只有跟我玩得特别好，认识我很多面的人，才会知道我是什么样的人，但也因此更难以总结和评价我。

我不清楚这是好是坏。

---

为什么要坚持 review 并写下来？

既然 review 对我来说要耗费比聪明人更多的精力，我为什么还要坚持这么做呢？

因为我健忘啊(✿◡‿◡)
只有写下来，我才知道原来我对它还有过这样的思考；
只有写下来，我才有更多的印象，下次直接找到，然后完善和修正它，而不用重头再来了；
只有写下来，我才能发挥出我强大的检索能力，一般我也会留下足够的继续搜索的信息；
只有写下来，我才能在和别人讨论到的时候，直接帅气地甩链接给对方，既可以节约沟通时间，也可以帮助到别人（我真的研究了挺多有意思、实用的东西呢！）

以上这段话，可以总结为：怕麻烦，因为我懒；怕以后更麻烦，所以现在麻烦一下。

其实我是个懒人。

---

我所看重的 review 的意义

1. 对这件事而言：同一个坑，不要再踩
2. 对这类事而言：警惕同样类型的错误，还有没有其他样子的坑
3. 对不同类事 但同一个道理而言：也许能生发出更深层的教训或心得，它也适用于其他领域的

这三种层次，一个比一个更深。
但不是每次 review 都能达到第三层效果的，值得说明的是，我不反对从一件芝麻小事里提取到第三层效果，但这个效能真的太差。

每件事本身的类型、错误、后果都不一样，它们能带来的初始势能也不相同。一件芝麻小事，大部分只能汲取到第一层效果，它很难去转化成第二层、第三层，即便能，花的时间精力不亚于去思考一个哲学问题。

何必呢？咱们时间有限。

何况我不觉得生活中会缺少大事，那种自带 buff 的大事，它的初始势能也许能直接冲到第二层，努努力就到了第三层。

遇到这种情况，卯足了劲去琢磨和回顾。我想这也是为什么在大厂的人能成长快的原因吧，这样的大事多呗~

---

review 的附带效果

以我浅薄的经验，暂时发现了下面两点：

1. 找到错误的原因，你会发现你自己、其他同事各自的盲区，通过这次协作，能增进互相的了解，下次配合得更棒。如果是专业知识的问题，那就提供了努力的方向
2. 给后来者提供了不错的资料，如果是经过认真整理的资料就更棒了（我尤其喜欢 wiki 和 github）