你的工程项目组有没有过这样的经历：合作开发工作效率低，招了许多人，天天上工，出活却不多，圣戈当斯区bug多发，领导失态，底层无能为力，技师埋怨不断，搜寻bug十分困难。其实那些都是标识符产品质量差惹的祸。标识符产品质量是研制产品质量管理的根本，它决定了整座合作开发工程项目组的合作开发工作效率，工程项目产品质量，其他监控，监视系统，笔记等手段都只能是事前补偿。责任编辑就如何确保标识符产品质量总结了许多经验和方式，供我们参考。

标识符产品质量本身并没有两个不光明确的定量指标，因此根据公司发展的相同阶段，工程项目组规模的大小相同，工程项目性质的相同等，对标识符产品质量的明确要求也各不相同．不过如果工程项目中出现以下情形这时候，就说明标识符产品质量要值得倚重了．

加进或修正两个简单机能时，涉及要修正的地方不光多，因此很分散；

标识符不可F83E43Se：相似的机能难以F83E43Se标识符，要重新合作开发；

圣戈当斯区bug多发，排错十分困难，复原难度大，时间长；

有许多奇怪的标识符，标识符读要学，后辈难以很快了解标识符；

标识符月眉不光多，不敢大动，白白就踩坑；

以内那些难题，基本上都是标识符产品质量不高引致的，包括标识符无注解，无文件格式，重新命名差，工程项目体系结构差，初始化关系混乱，到处hardcode，临时软件系统等等。是不是才能时刻确保标识符的高产品质量，避免以内难题发生？当然工程项目组的技术素养很重要，除此以外，还有许多方式变易的．

1. 不屑一顾似地继续执行代码规范化

严格继续执行标识符撰写规范化，能使两个工程项目乃至两个公司的标识符具有完全统一的风格，就像同两个人撰写的一样，因此重新命名良好的表达式，表达式，类和注解，也无疑能提升标识符的时效性．具体内容落实到继续执行层面，能参考Google的代码规范化或是java官方的代码规范化，网上能找到，关键性是要遵守，因此在code review时，严格把关，没有按照规范的一定要指出因此明确要求修正．

实际情形往往是虽然我们都知道优秀的标识符规范化是怎样的，但在具体内容写标识符的过程中，却继续执行的不尽人意，许多情形是认识上不如倚重，真的两个表达式或是表达式的重新命名成Ambroix毫无关系，因此不如推敲，注解许多也都不写，code review的这时候我们也都可有可无心态，或是真的没必要太抠细节，引致慢慢的整座code base变得越来越差．因此这里还是要强调一下，香简草存亡，提升工程项目组对标识符规范化的尊重及其严格的继续执行是关键性．

2. 撰写高产品质量的单元测试

单元测试是最容易继续执行，且对提升标识符产品质量见效最快的方式之一还。但还是有许多公司对单元测试倚重不如，包括许多大的互联网公司，不写或是随便写写。

有些技师真的有测试工程项目组就够了，再写单元测试就是浪费时间。其实测试工程项目组的测试和单元测试是在相同层面上的，测试工程项目组的测试一般是黑盒测试，系统层面的集成测试，对于复杂系统来说，组合爆炸，测试工程项目组难以穷举所有的测试用例。单元测试是标识符层面的测试，一般是针对类的测试。既然难以从系统的整体上确保100%符合我们的预期，那单元测试起码能确保我们标识符在细粒度上运行符合预期。

有些技师认为合作开发任务重没时间写。这个还是没有足够倚重单元测试，真的是可有可无的部分，才会有这样的想法。写好单元测试，节省许多解决圣戈当斯区bug的时间，合作开发时间反而更充足了。

还有许多技师虽然在写单元测试，但只对正常流程做测试。标识符中的bug多数是写代码时异常情形没有考虑全面引致的，正常流程一般不会出难题。单元测试的作用就在于测试各种异常情形下标识符的运行是否符合预期，因此只对正常流程测试难以发挥单元测试真正的作用。

一般情形下，单元测试标识符量要比要测试的标识符多，一般是1-2倍的样子，写单元测试本身没有太多的技术挑战，主要看技师逻辑是否缜密，能够考虑各种异常情形，写起来比较枯燥，因此写高产品质量的单元测试的一方面要靠技师的耐心继续执行，另一方面要靠工程项目组的严格把关。当然那些都是建立在对单元测试重要性的尊重之上。

3. 不流于形式的Code Review

如果说单元测试许多技师不是不是倚重，那code review就是不是不是接受．跟许多大型互联网公司的人聊过，对code review都不是不是认可，大部分反应都是，这玩意不可能很好的继续执行，浪费时间，是的，code review做的再流畅，也是要花时间的，关键性在于我们是愿意花2天写标识符花5天修bug,还是愿意花３天写标识符花半天修bug.

其实，code review的好处不仅仅是能够大大提升标识符产品质量，减少标识符bug，你想想如果我们没有code review，平时写的标识符“偷偷”就commit了，难免有人不自律，有了code review，直播标识符，曝光dirty code，我们就会更认真些．其次来讲，code review也是一种有效技术传帮带的途径，每次code review都是一次案例的剖析，能帮助初级的技师培养代码规范化，提升代码产品质量，设计能力甚至于架构能力，反过来，review别人写的好的标识符，对自己也是一种学习和提升．

除此以外，严格的code review不仅能确保标识符的产品质量，还能形成良好的技术氛围。

4. 合作开发未动文件格式先行

撰写技术文件格式对大部分技师来说都是挺反感的事情。一般来讲在合作开发某个系统或是重要模块或是机能之前需要先写技术文件格式，然后发送给同组或是相关同事审查，在审查没有难题的情况下再合作开发，这样能够事先达成共识，合作开发出来的东西不至于走样，因此当合作开发完成之后进行code review的阶段，标识符审查者通过阅读合作开发文件格式也能快速的理解标识符．

除此以外，文件格式对于工程项目组和公司来讲都是重要的财富，对于后辈加入公司熟悉标识符，产品，对于任务的交接等等都很有帮助，因此作为两个规范化化的技术工程项目组，技术文件格式是一种摒弃作坊式合作开发和个人英雄主义的有效方式，是确保工程项目组有效协作的途径．

不过，有许多技师提出说不会写技术文件格式，不知道写什么，希望给两个模板或是目录．我之前曾经想过是否能给出两个固定的模板，但最后还是放弃了，比较难，难点在于，每个工程项目侧重点都不一样不容易总结，如果硬要给出两个很宽泛的目录，不具有指导性也没有意义．大体上来讲，文件格式的内容主要是将做的东西讲清楚，包括出难题背景，解决了什么难题，外部是不是用或初始化，内部如何实现，大的架构，关键性机能和算法等，以及许多非机能性的考虑。

5. 持续重构，重构，重构

个人比较反对平时不注重标识符产品质量，堆砌烂标识符，实在维护不了了就大刀阔斧的重构甚至重写。有这时候工程项目标识符太多了，重构很难做到彻底，最后又搞出来两个四不像的怪物，更麻烦了！

优秀的标识符或架构不是一开始就能完全设计好的，就像优秀的公司或产品也都是迭代出来的一样的，我们难以100%遇见未来的需求，也没有足够的精力，时间，资源为遥远的未来买单，因此随着系统的演进，重构标识符也是不可避免的，虽然上面说了不支持大刀阔斧推到重来式的大重构，但持续的小重构还是比较推崇的，也是时刻确保标识符产品质量防止标识符腐化有效手段．简单一句话就是不要等到难题堆得太多了再采取重构，要时刻有人对标识符整体负责任，平时没事就改改标识符，而不要真的重构标识符就是浪费时间，不务正业！

不光是许多业务合作开发工程项目组，有这时候为了快速完成两个产品或是业务机能，只追求速度，到处hard code，在完全不考虑非机能性需求的情形下，堆砌许多烂标识符，这种情形还是比较常见的。不过没关系，等有时间一定要记着重构，不然烂标识符越堆越多，总有一天会没人能维护。

6. 工程项目与工程项目组”微服务化”

只有小工程项目是能维护的，大工程项目是难以维护的．工程项目组人比较少的这时候，十几个人的样子，标识符量也不多，不超过10万行，是不是合作开发，是不是管理都没难题，我们互相都了解彼此做的东西，标识符产品质量太差了，大不了重写一遍．但如果是两个极其庞大的工程项目，几十万行标识符，几十个合作开发维护，那基本上没人能对标识符负责了．

因此当工程项目太大了之后，就需要对标识符和工程项目组进行拆分，模块化，大工程项目组拆成几个小工程项目组，大工程项目拆成几个小工程项目，这样每个工程项目组每个工程项目的标识符都不至于许多，也不至于出现标识符产品质量太差难以维护的情形，其实许多技术也都体现了这种思想，比如大到soa, 微服务，小到jar, .so等lib模块合作开发，Class类的封装，都是一种拆分的思想．

以内其他的所有方式都是治标不治本，找到对的人用好对的人，打造优秀的技术文化，才是能一直卓越的根本。有许多技师比较热衷于学习架构，工具，框架层面的东西，见过许多技师，还没写三五年标识符就转做架构师，不写标识符了，到处忽悠，很不好，互联网信息如此透明，相同的人去做同两个工程项目，其实最后设计出来的架构,机能大约都差不多，最后我们都能把这个系统实现，但有些人做出来的系统，bug许多，性能很差，扩展性也不好，最多能叫个POC。

高手之间的竞争还是在于细节，两个算法够不如优化，数据存取的工作效率高不高，内存是否够节省等等，这是累积起来决定了两个系统是不是够优秀。

当然并不是说框架，工具，架构设计那些方面的学习不重要，关键性是有深度，希望是实践中锻炼得来的，而不是到处看微

国内技师普遍深度不如，做几年技术就转管理或是纯架构设计不写标识符了，而国外不一样，大龄码农许多，因此国外的优秀开源工程项目比较多，而国内很少。

8. 工欲善其事必先利其器

标识符中的许多低级产品质量难题不需要人工去审查，java合作开发有许多现成的工具能使用，比如：checkstyle，findbugs, pmd, jacaco, sonar等。

Checkstyle,findbugs,pmd是静态标识符分析工具，通过分析源标识符或是字节码，找出标识符的缺陷，比如参数不匹配，有歧义的嵌套语句，错误的递归，非法计算，可能出现的空指针引用等等。三者都能集成到gradle等构建工具中。

Jacoco是一种单元测试覆盖率统计工具，也能集成到gradle等构建工具中，能生成漂亮的测试覆盖率统计报表，同时Eclipse提供了插件能EclEmma能直观的在IDE中查看单元测试的覆盖情形。

Sonar Sonar 是两个用于标识符产品质量管理的平台。能在两个统一的平台上显示管理静态分析，单元测试覆盖率等产品质量报告。

最后，总结

以内所有的那些方式论应该都没啥新奇的，也没有葵花宝典似的杀手锏，说出来感觉都很简单的，现在互联网这么发达，信息都很透明，因此大方向我们都知道，具体内容的策略和架构各家也都差不多，最后谁做的好，关键性在于继续执行和细节，经常听到有人说我们做了单元测试啊，我们做了性能测试，可最后还是一堆性能问题一堆bug，那就要去考虑一下到底做的够不如好，是否做到了具体内容难题具体内容分析，不生搬硬套，从决策到继续执行再到考核是否形成了闭环，许多这时候只是空喊口号，口号喊得100分，落实到继续执行只能得５0分，最后又完全没考核，好坏我们也都不知，切记敏于言而讷于行。

链接：

https://juejin.im/post/5c88ac2b5188257dda56c87e