我参加过几次R & amp我见过研发团队。很多公司的d团队。每当我和程序员聊天或者和研发人员联系时。d队，我总能对一个人或者一个团队的技术实力做出快速判断。虽然不一定客观，但也形成了一套方法论。这段时间我会把这种感觉解读成多个元素，一个一个写出来，从代码评审开始。 　　

　　

　　代码审查是软件团队的重要文化组成部分。一个好的代码评审机制不仅可以共同提高团队，还可以有效增加团队交流，促进互补氛围的形成。每个团队成员都可以通过分享自己的代码和学习别人的代码来不断打磨和提高自己的技能。 　　

　　

　　解决问题的思路和方法很多。通过代码审查，我们可以尽可能地找到最佳解决方案。在一个成熟的技术团队中，向源码库提交代码应该是一件很神圣的事情。在提交之前，我们应该仔细检查自己的代码。同时，使用代码检查工具可以让代码检查过程如同论坛灌水一样，形成围观效应。让每一个加入团队的新人都感受到前几次提交代码的艰辛，有过五关斩六将的感觉。如果能提交问题0的代码，团队成员应该会感到满满的成就感和荣誉感。我们来谈谈代码评审应该包含哪些内容。 　　

　　

　　架构设计单一责任原则具体来说就是一个类或者一个方法只有一个指责，说起来容易做起来难。一般我们可以通过一个简单的方法来判断，就是如果需要用“和”这个词来描述这个方法或者这个类的责任，那么就要对代码进行进一步的抽象和优化。 　　

　　

　　开放封闭原则是指一个功能模块，应该开放扩展，封闭修改。如果一个程序只考虑第一种和第二种情况，当第三种和第四种情况来临时，需要大量的代码修改，就需要继续抽象。 　　

　　

　　代码重复目前很多ide都有自己的代码重复检测功能，但是最好看一下代码审查。复制代码是程序员最糟糕的习惯，必须进行重构。在实践中，不必如此严格。对于几行的重复，可以采用不超过三件的原则。重复两次可以原谅，重复三次必须叫回来修改。 　　

　　

　　眯着眼测试在PPT检查中经常用到眯着眼测试，就是不看细节的眯着眼，看看是否还能感受到PPT的内容。眯着眼测试用在代码评审中，就是看代码的大结构而不看代码的细节，看能不能感觉到一些潜在的问题。很玄学，但有时候很有效。 　　

　　

　　以积极的方式修改代码有时会改变一个bug，通常会在错误代码附近添加几行代码。虽然能解决问题，但不优雅。我们应该进一步思考，是否能以更好的方式解决这个问题，而不是简单地打补丁。 　　

　　

　　潜在问题：数组有没有可能越界？循环会不会以意想不到的方式被打断？变量线程安全吗？参数有可能是空的吗？等一下。 　　

　　

　　处理错误是否所有错误都得到妥善处理？异常处理是否具体有效？您使用了标准自定义错误，还是自己创建了一个？ 　　

　　

　　性能重点检查带遍历的代码、数据结构、遍历方法是否合适，能不能不做遍历？内存副本是深度副本还是轻度副本，使用是否得当？ 　　

　　

　　风格方法名和方法名是否符合整个团队的代码规范？方法名和方法内容一致吗？ 　　

　　

　　变量名变量名应该清晰具体。不要随心所欲地使用缩写或简称。你在给它命名时一定要讲究。永远记住提交代码是一件神圣的事情，每个细节都要完美。变量名应该符合团队编码标准。如何区分参数名、类变量、方法变量和临时变量？ 　　

　　

　　方法的长度不应超过20个字符。如果太长，尽量剪短。 　　

　　

　　一节课的长度不应超过300行。对于超长的类，应该考虑切割成多个类，以便于理解。 　　

　　

　　对于不同的语言，文件长度应有不同的文件限制。目的是减轻程序员的精神负担。 　　

　　

　　注释应该以有利于代码文档生成的方式编写。下一篇文章将讨论持续集成。 　　

　　

　　注释的代码删除所有注释的代码。 　　

　　

　　参数的数量不应超过三个。如果多于三个，考虑是否应该将其封装到一个结构中。 　　

　　

　　代码的可读性是否容易理解，读代码时是否经常block。 　　

　　

　　测试覆盖率达到理想的代码覆盖率了吗？测试全面吗？是否涵盖了所有故障条件？测试代码容易理解吗？测试性能还可以吗？ 　　

　　

　　测试是否处于合适的水平要根据不同的功能来确定，合理选择单元测试和集成测试的比例，一般单元测试95%，集成测试5%。 　　

　　

　　mock的数量mock是很有用的，但是一套测试中的mock太多是不好的，要么是测试范围太广，要么是测试的功能太大。总是减少模拟的数量，最好不超过3个。 　　

　　

　　不管是否符合要求，开发最重要的目标是符合要求。不管是bug还是新功能，如果不符合要求，就必须重新改。 　　

　　

　　提交前做好自查。再次强调，提交代码，包括提交代码评审，是非常神圣的。在进行全面自检之前，可以使用diff命令来比较这个提交代码和之前版本的区别。你可以检查几个问题： 　　

　　

　　代码中有TODO留下的名字吗？他们是挑剔的，而不是随机的吗？之前提到的问题。提交代码的时候一定要有信念，让别人审核没有任何问题！ 　　

　　

　　代码评审是如何互动的？无论是评审别人还是被评审，在代码评审的过程中肯定会有交互。如何才能实现有效的互动？可以参考以下原则： 　　

　　

　　这种提问方式是如何运作的？如果需求发生变化，这部分怎么办？ 　　

么改呢？这段代码怎么写才能更好维护呢？

　　

看到亮点多多赞美和鼓励代码审查一个重要的作用就是帮助程序员成长，多多咱们程序员做的好的地方，会让他们备受鼓舞，并且能让整个团队处于一个很好的氛围。

　　

讨论细节一般代码审查都是在工具上进行，但是有的时候问题非常负责，在代码审查工具上一问一答的进行效率不高，这个时候不如开小会讨论一下，然后再把结论发到review工具上去。

　　

解释原因代码审查的主观性很强，对于其他人的观点，如果认为有异议，要敢于进行解释，不要有太多顾虑，而且有的时候，代码审查不能看到所有的背景知识，所以解释是很必要的。

　　

对代码不对人在整个代码审查的过程中，主要目的就是提升代码的质量，不要再代码审查中讨论到人，只讨论代码，这点很重要。

　　

写明问题的重要程度有些问题必须要改，不改需要写回复解释原因，有些问题是建议性的，改不改主动权在程序员自己。

　　

对代码审查的态度首先，程序员的工作就是写出可以工作并且易于维护的代码，但是由于交付的压力，很多程序员都不太注意第二点，甚至很多程序员认为代码可以工作是最重要的，是不是能维护无所谓，这个氛围蔓延开来，不但不利于产品质量的提升，也不利于程序员自身技术的提高。重构的目的不是改变程序的行为，而是让程序变得更好维护，而程序的可维护性其实和修复bug一样重要。

　　

其次，在整个代码审查过程中要保持开放的心态，这点其实有点儿反人性，每个人都不希望被批评，但是我们还是要努力训练一下，代码审查的过程是为了让我们变得更强，所以还是抑制一下自己与生俱来的自尊心吧。

　　

最后就是对于他人提出的意见，如果没有明确不改的理由，最好能改就改，因为软件开发是一项团队工作，如果这个问题让一个人产生了困惑，说明很多有可能会造成更多人的困惑，时刻记住，你写的代码不是你一个人看懂就可以的。

　　

代码审查工具和流程这部分内容我想放到CI/CD部分去写，大概来说，每段代码都要团队中两个以上人去审核，而且要用特定的代码审查工具，整个的过程要自动化，流水线作业。

　　

推荐书籍还是要推荐几本书，知行合一

　　

第一本是《代码大全》，提供编程的基础思想，第二本是《重构》，第三本是《程序员修炼之道》，这本书虽然名字有些俗气，但是书确实是好书。