代码审查
最近准备在项目内推行代码审查，整理最近学到有关代码审查有关知识
从代码审查里能得到什么？
很显然：在代码提交前，用第二只眼睛检查一遍，防止bug混入。这是对其最常见的理解，是对代码审查好处的最广泛认识。但是，这反倒是它最不重要的一点。人们确实在代码审查中找到了bug。可是，这些在代码审查中能发现的绝大部分bug，很显然，都是微不足道的bug，程序的作者花几分钟的时间就能发现它们。真正需要花时间去发现的bug不是在代码审查里能找到的。
代码审查的最大的功用是纯社会性的。如果你在编程，而且知道将会有同事检查你的代码，你编程态度就完全不一样了。你写出的代码将更加整洁，有更好的注释，更好的程序结构。因为你知道，将会有人查看你的程序。没有代码审查，你知道人们最终还是会看你的程序。但这种事情不是立即发生的事，它不会给你带来同等的紧迫感，它不会给你相同的个人评判的那种感受。
还有一个非常重要的好处。代码审查能传播知识。在很多的开发团队里，经常每一个人负责一个核心模块，每个人都只关注他自己的那个模块。除非是同事的模块影响了自己的程序，他们从不相互交流。这种情况的后果是，每个模块只有一个人熟悉里面的代码。如果这个人休假或辞职，其他人则束手无策。通过代码审查，至少会有两个人熟悉这些程序(作者和审查者)审查者并不能像程序的作者一样对程序十分了解，但他会熟悉程序的设计和架构，这是极其重要的。
好处：提高代码质量；知识分享；沟通交流
当然，没有什么事情能简单的做下来的。在你能正确的进行代码审查前，你需要花时间锻炼学习。我发现人们在代码审查时经常会犯一些错误，导致不少麻烦，尤其在一些缺乏经验的审查者中经常的出现，他们给了人们一个很遭的代码审查的体验，成为了人们接受代码*的一个障碍。
最重要的一个原则：代码审查用意是在代码提交前找到其中的问题，你要发现是它的正确。在代码审查中最常犯的错误，几乎每个新手都会犯的错误，即审查者根据自己的编程习惯来评判别人的代码。
对于同一个问题，通常我们能找出十几种方法去解决。对于一种解决方案，我们能有百万种编码方案来实现它。作为一个审查者，你的任务不是来确保被审查的代码都采用的是你的编码风格，因为它不可能跟你写的一样。作为一段代码的审查者的任务是确保由作者自己写出的代码是正确的。一旦这个原则被打破，你最终将会倍感折磨，深受挫折，这可不是我们想要的结果。
问题在于，这种错误是如此的普遍而易犯。如果你是个程序员，当你遇到一个问题，你能想到一种解决方案，你就把你想到的方案作为标准答案。但事情不是这样的，作为一个好的审查者，你需要明白这个道理。
代码审查的第二个易犯的毛病是，人们觉得有压力，感觉非要说点什么才好。你知道作者用了大量的时间和精力来实现这些程序。
不该说点什么吗？
不，你不需要。
只说一句“哇，不错呀”，任何时候都不会不合适。如果你总是力图找出一点什么东西来批评，你这样做的结果只会损害自己的威望。当你不厌其烦的找出一些东西来，只是为了说些什么，被审查人就会知道，你说这些话只是为了填补寂静。你的评论将不再被人重视。
不是在鸡蛋中挑骨头
第三是速度(半个小时足以)。你不能匆匆忙忙的进行一次代码审查，但你也要能迅速的完成。你的同伴在等你。如果你和你的同事并不想花太多时间进行代码复查，你们很快的完成，那被审查者会觉得很沮丧，这种代码审查带来的只有失望的感觉。就好象是打搅了大家，使大家放下手头的工作来进行审查。事情不该是这样。你并不需要推掉手头上的任何事情来做代码审查。但如果中途耽误了几个小时，你中间还要休息一会，喝杯茶，冲个澡，或谈会儿闲话。当你回到审查现场，你可以继续下去，把事情做完。如果你真是这样，我想没有人愿意在那干等着你。
实践方式：
- 一次评审少于 200–400 行的代码。
- 目标为每小时低于 300–500 LOC 的检查速率。
- 花足够的时间进行正确缓慢的评审，但是不要超过 60–90 分钟。
- 确定代码开发者在评审开始之前就已经注释了源代码。
- 为代码评审和获取制度建立可定量化的目标，这样您才能改进流程。
- 使用检查列表，因为它可以极大地改进代码开发者和评审者的作品。
进入条件：
需求开完好就进入代码审查，开发人员对自己代码及设计方案还很熟悉，复审效率更高，也能提前发现方案的不合理
检查表示例：
