代码审查是一个软件团队的重要文化组成部分，一个好的代码审查机制不但能使团队共同提高，还能有效增加团队沟通，促进形成相互补位的氛围。每个团队成员可以通过分享自己的代码以及学习他人的代码不断打磨和提高技术。
解决问题的思路和方法有很多，通过代码审查，可以尽可能的找到其中最优的解决方案，在一个成熟的技术团队中，提交代码到源码仓库应该是一件很神圣的事情，在提交之前应该认真的检查自己的代码，同时，使用代码检查工具，可以让代码检查过程就像论坛灌水一样，形成围观效应。应该让每个加入团队的新人，都能感觉得前几次提交代码的艰辛，要有过五关斩六将的感觉。如果能做到0问题的代码提交，应该让团队成员感到充分的成就感和荣誉感。下面就来说下代码审查（code review）应该包含哪些内容。
架构和设计单一职责原理具体来说就是一个类或者一个方法有且仅有一个指责，说起来容易做起来难，一般我们可以用一个简单的方法判断，就是如果我们需要用“和”字去描述这个方法或者这个类的职责，那么就应该进一步对代码进行抽象和优化。
开闭原则是指一个功能模块，对扩展应该是开放的，对修改应该是封闭，如果一个程序只考虑了第一种和第二种情况，而当第三种和第四种情况到来时需要大量修改代码，这就需要继续抽象了。
代码重复目前很多IDE自带了代码重复检测功能，但是code review时最好还是看一看，复制代码是一个程序员最不好的习惯，必须要重构，实际操作中也不一定非要那么严格，对于少数几行重复的情况，可以采用事不过三的原则，重复两次可以原谅，重复三次必须打回去修改。
眯眼测试眯眼测试常常用在PPT的检查上，就是眯起眼来不看细节，看看还能不能感受到PPT要讲的内容，眯眼测试用在代码审查上，就是不看代码细节，只看代码大块结构，看看是不是能够感受到一些潜在问题，很玄学，但是有时很有效。
用积极的方式修改代码有时候改一个bug，经常是在出问题的代码附近增加几行，虽然能解决问题，但是不优雅，应该更进一步想想，能不能用更好的方式解决这个问题，而不是简单的打个补丁。
潜在问题是否有可能存在数组越界？循环是否会通过非期望的形式中断？变量是否是线程安全的？参数是否有可能为空？等等。。。
错误处理是不是所有的错误都被妥善处理？异常处理是不是具体并且有效？是不是使用了规范的自定义错误，还是自己随便创建了一个？
性能着重查看存在遍历的代码，数据结构和遍历方法是否得当，能不能不做遍历？内存拷贝是深拷贝还是浅拷贝，用法是否得当？
代码风格方法名方法名是否符合团队整体的代码规范？方法名称是否与方法内容相一致？
变量名变量名应该明确且具体，不要自己随心所欲的用简写或者缩写，起名字一定要考究，随时记住提交代码是一件神圣的事情，每个细节都要做完美。变量名一样要符合团队编码规范，参数名、类变量、方法变量、临时变量，如何区分？
方法长度方法长度最好不要超过20个字符，如果超长，想办法切短。
类长度一个类最好不要超过300行，对于超长类要考虑切分成多个，以便于理解。
文件长度对于不同的语言，应有不同的文件限制，宗旨就是降低程序员的心智负担。
代码注释应该按照便于生成代码文档的方式写注释，关于持续集成，后面的文章会讨论。
注释的代码删除所有注释的代码。
方法参数的个数最好不要超过三个，超过三个考虑是否应该封装成结构体
可读性代码是否容易理解，读代码的时候是否经常block。
测试测试覆盖率是否达到了理想的代码覆盖率？测试是否全面？是否覆盖了所有失败条件？测试代码容易理解么？测试性能OK么？
测试是否处于合适的级别应该根据功能的不同确定不同的测试级别，合理选择单元测试和集成测试的占比，一般是95%的单元测试+5%的集成测试。
mocks的数量mock非常有用，但是一套测试中mock的数量太多就不好了，要么就是测试范围太广，要么就是测试的功能太大，总是要减少mock的数量，最好不要超过3个。
是否符合需求开发最重要的目标还是满足需求，不管是bug还是新功能，如果不满足需求，肯定要重新改的。
提交审查之前先做自我审查再次强调提交代码，包括提交代码审查是非常神圣的，之前要做充分的自查，可以用diff命令，比较下本次提交代码与上一版的不同，可以查看几个问题：
是否还有TODO遗留在代码里各种名字起的是不是很考究了，而不是很随意的状态之前提到的各种问题。。。提交代码一定要有一个信念，让其他人review不出来任何问题！
不管是审查别人还是被审查，代码审查的过程中肯定会进行互动，如何做到有效互动呢？可以参考以下的一些原则：
问提题这个方法怎么工作呢？如果需求变化了，这部分应该怎么改呢？这段代码怎么写才能更好维护呢？
看到亮点多多赞美和鼓励代码审查一个重要的作用就是帮助程序员成长，多多咱们程序员做的好的地方，会让他们备受鼓舞，并且能让整个团队处于一个很好的氛围。
讨论细节一般代码审查都是在工具上进行，但是有的时候问题非常负责，在代码审查工具上一问一答的进行效率不高，这个时候不如开小会讨论一下，然后再把结论发到review工具上去。
解释原因代码审查的主观性很强，对于其他人的观点，如果认为有异议，要敢于进行解释，不要有太多顾虑，而且有的时候，代码审查不能看到所有的背景知识，所以解释是很必要的。
对代码不对人在整个代码审查的过程中，主要目的就是提升代码的质量，不要再代码审查中讨论到人，只讨论代码，这点很重要。
写明问题的重要程度有些问题必须要改，不改需要写回复解释原因，有些问题是建议性的，改不改主动权在程序员自己。
对代码审查的态度首先，程序员的工作就是写出可以工作并且易于维护的代码，但是由于交付的压力，很多程序员都不太注意第二点，甚至很多程序员认为代码可以工作是最重要的，是不是能维护无所谓，这个氛围蔓延开来，不但不利于产品质量的提升，也不利于程序员自身技术的提高。重构的目的不是改变程序的行为，而是让程序变得更好维护，而程序的可维护性其实和修复bug一样重要。
其次，在整个代码审查过程中要保持开放的心态，这点其实有点儿反人性，每个人都不希望被批评，但是我们还是要努力训练一下，代码审查的过程是为了让我们变得更强，所以还是抑制一下自己与生俱来的自尊心吧。
最后就是对于他人提出的意见，如果没有明确不改的理由，最好能改就改，因为软件开发是一项团队工作，如果这个问题让一个人产生了困惑，说明很多有可能会造成更多人的困惑，时刻记住，你写的代码不是你一个人看懂就可以的。
代码审查工具和流程这部分内容我想放到CI/CD部分去写，大概来说，每段代码都要团队中两个以上人去审核，而且要用特定的代码审查工具，整个的过程要自动化，流水线作业。
推荐书籍还是要推荐几本书，知行合一
第一本是《代码大全》，提供编程的基础思想，第二本是《重构》，第三本是《程序员修炼之道》，这本书虽然名字有些俗气，但是书确实是好书。
