618备战利器

     过了多次618，每次都是吃吃喝喝，今年的618着实给我上了一课。首先不说事件的起因，也不说时间的结果，看官你要问了，不说原因也不说结果，你说什么？我只说这堂课我学到了什么–代码评审有必要日常化。
代码评审大家都曾经历过，偶尔过年的时候就会有段子说某某CTO年会review抽奖代码，评审代码给我带来什么呢？仅仅是找出几个bug吗？我想除此之外会有以下几点用途。

1.保证代码规范性
     对于一个长期维护的系统，最难的部分就是维护不断堆砌的业务代码。如果再没有一个规范的代码标准，后续接手人遇到问题将束手无策，这里推荐一下《阿里巴巴java开发手册》。有了规范就可以了吗？答案是否定的，为什么呢？源于人的懒惰本性。每个程序员总是习惯于已经习惯的代码编写方式，即使很烂，如果没有人提醒他，他仍会持续下去，而一旦一个系统添加进了坏味道的代码，就会有更多像苍蝇一样随之而来的坏味道代码。所以要第一时间纠正不规范的编码习惯，保证系统代码的纯净性。

2.纠正逻辑错误
     三个臭皮匠顶个诸葛亮的思考来源于群众的力量是无穷的。一个人审查自己的代码，往往会陷入固有思维，对已存在的逻辑错误视而不见。这也是为什么推荐结对编程的原因，不过往往结对编程会因为业务的不断催促变的形式化。面对大促时，集中代码评审，不仅可以让程序员们舒一口气，同时可以集中力量找bug。

3.同步最新业务需求
     在日常的工作中，如果你是使用敏捷开发，就会在日常例会上总结自己每天做什么，同时也会听到别人在做什么，不过你确定真的知道别人在做什么吗？答案往往是例会上多数人会关注自己的事情多余关注别人，所以对于整体系统而言，多数人是只见树木不见森林，只知道用了他人RPC服务，具体怎么实现的不了解。

4.分享技术干货
     每个人都有表演的欲望，而程序员的表演莫过于指尖上ABC，所以让程序员show一段舞蹈，不如让他们展示一下他们优雅的代码。代码评审不仅让每个人熟悉了系统架构，同时也让每个人见到了其他人的智慧闪光点。可以让新入行的小白学习老司机如何开大车，也可以让老白兔知道自己正在被新技术所淘汰。

     综上所述，代码评审有必要日常化，特别是在应对大促时，是梳理备战点的神兵利器。