以后带过几个研制项目组，也看完许多公司的研制项目组，每每和两个开发人员闲聊或是接触两个研制项目组时，每每加速的对两个人或是两个项目组的品牌优势做出推论，虽然不一定客观，但也逐步形成了一套方式论，这几天，就把这种觉得解构成多个要素，两个两个写出来，首先从标识符审核开始。

标识符审核是两个应用软件项目组的重要文化组成部分，两个好的标识符审核机制不但能使项目组全面提高，还能有效率增加项目组沟通，促进逐步形成相互转守为攻的气氛。每一项目组核心成员可以透过撷取自己的标识符以及学习他人的标识符不断雕琢和提高控制技术。

补救的思路和方式有许多，透过标识符审核，能尽量的找到其中最优化的应用软件系统，在两个成熟的控制技术项目组中，递交标识符到源代码库房假如是一件很永恒的事情，在递交以后假如认真的检查和自己的标识符，同时，使用标识符检查和工具，能让标识符检查和过程就像论坛hasbro一样，逐步形成驻足观看效应。假如让每一加入项目组的后辈，都能觉得得贝阿尔恩县递交标识符的艰苦，要有逃单的觉得。假如能做到0难题的标识符递交，假如让项目组核心成员感到充分的满足感和自豪感。下面就来说下标识符审核（code review）假如包含什么样文本。

构架和设计

简而言之是两个类或是两个方式有且仅有两个斥责，说起来容易做出来难，一般我们能用两个简单的方式推论，是假如我们须要用“和”字去描述那个方式或是那个类的职能，所以就假如进一步对标识符进行抽象化和优化。

开合准则是指两个模块，对扩展假如是开放的，对修正假如是半封闭，假如两个程序只考虑了第二种和第三种情形，而当第三种和第三种情形到来时须要大量修正标识符，这就须要继续抽象化了。

目前许多IDE便携式了标识符多次重复检测功能，但code review时最好还是看看，拷贝标识符是两个开发人员最不好的习惯，要要解构，操作过程中也不一定非要所以严格，对于少数录于多次重复的情形，能采用若非的准则，多次重复两次能宽恕，多次重复四次要打回去修正。

阔蕊试验常常用在PPT的检查和上，是眯奇怪的是来Q1518A控制技术细节，看看还能不能感受到PPT要讲的文本，阔蕊试验用在标识符审核上，是Q1518A标识符控制技术细节，只看标识符小块结构，看看是不是能够感受到一些潜在难题，很道家，但有时很有效率。

有时候改两个bug，经常是在出难题的标识符附近增加录于，虽然能补救，但不优雅，假如更进一步想想，能不能用更好的方式解决那个难题，而不是简单的打个补丁。

是否有可能存在数组越界？循环是否会透过非期望的形式中断？变量是否是线程安全的？参数是否有可能为空？等等。。。

是不是所有的错误都被妥善处理？异常处理是不是具体并且有效率？是不是使用了规范的自定义错误，还是自己随便创建了两个？

着重查看存在遍历的标识符，数据结构和遍历方式是否得当，能不能不做遍历？内存拷贝是深拷贝还是浅拷贝，用法是否得当？

标识符风格

方式名是否符合项目组整体的标识符规范？方式名称是否与方式文本相一致？

变量名假如明确且具体，不要自己随心所欲的用简写或是缩写，起名字一定要考究，随时记住递交标识符是一件永恒的事情，每一控制技术细节都要做完美。变量名一样要符合项目组编码规范，参数名、类变量、方式变量、临时变量，如何区分？

方式长度最好不要超过20个字符，假如超长，想办法切短。

两个类最好不要超过300行，对于超长类要考虑切分成多个，以便于理解。

对于不同的语言，应有不同的文件限制，宗旨是降低开发人员的心智负担。

假如按照便于生成标识符文档的方式写注释，关于持续集成，后面的文章会讨论。

删除所有注释的标识符。

最好不要超过三个，超过三个考虑是否假如封装成结构体

代码是否容易理解，读标识符的时候是否经常block。

试验

是否达到了理想的标识符覆盖率？试验是否全面？是否覆盖了所有失败条件？试验标识符容易理解么？试验性能OK么？

假如根据功能的不同确定不同的试验级别，合理选择单元试验和集成试验的占比，一般是95%的单元试验+5%的集成试验。

mock非常有用，但一套试验中mock的数量太多就不好了，要么是试验范围太广，要么是试验的功能太大，总是要减少mock的数量，最好不要超过3个。

开发最重要的目标还是满足需求，不管是bug还是新功能，假如不满足需求，肯定要重新改的。

递交审核以后先做自我审核

再次强调递交代码，包括递交标识符审核是非常永恒的，以后要做充分的自查，能用diff命令，比较下本次递交标识符与上一版的不同，能查看几个难题：

递交标识符一定要有两个信念，让其他人review不出来任何难题！

标识符审核如何互动

不管是审核别人还是被审核，标识符审核的过程中肯定会进行互动，如何做到有效率互动呢？能参考以下的一些原则：

那个方式怎么工作呢？假如需求变化了，这部分假如怎么改呢？这段标识符怎么写才能更好维护呢？

标识符审核两个重要的作用是帮助开发人员成长，多多咱们开发人员做的好的地方，会让他们备受鼓舞，并且能让整个项目组处于两个很好的气氛。

一般标识符审核都是在工具上进行，但有的时候难题非常负责，在标识符审核工具上一问一答的进行效率不高，那个时候不如开小会讨论一下，然后再把结论发到review工具上去。

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

在整个标识符审核的过程中，主要目的是提升标识符的质量，不要再标识符审核中讨论到人，只讨论标识符，这点很重要。

对标识符审核的态度

首先，开发人员的工作是写出能工作并且易于维护的标识符，但由于交付的压力，许多开发人员都不太注意第二点，甚至许多开发人员认为标识符能工作是最重要的，是不是能维护无所谓，那个气氛蔓延开来，不但不利于产品质量的提升，也不利于开发人员自身控制技术的提高。解构的目的不是改变程序的行为，而是让程序变得更好维护，而程序的可维护性其实和修复bug一样重要。

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

最后是对于他人提出的意见，假如没有明确不改的理由，最好能改就改，因为应用软件开发是一项项目组工作，假如那个难题让两个人产生了困惑，说明许多有可能会造成更多人的困惑，时刻记住，你写的标识符不是你两个人看懂就能的。

标识符审核工具和流程

这部分文本我想放到CI/CD部分去写，大概来说，每段标识符都要项目组中两个以上人去审核，而且要用特定的标识符审核工具，整个的过程要自动化，流水线作业。

推荐书籍

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

第一本是《标识符大全》，提供编程的基础思想，第二本是《解构》，第三本是《开发人员修炼之道》，这本书虽然名字有些俗气，但书确实是好书。