怎么提升代码质量？-来自Google的研发经验总结

关注个人微信公众号：小争哥，获取更多、更新的技术、非技术分享。
做者：前Google工程师，5万人订阅《数据结构和算法之美》专栏做者。
但愿经过我加速你的技术、职场进步。

你的团队有没有过这样的经历：开发效率低，招了不少人，每天加班，出活却很少，线上bug频发，领导发飙，中层一筹莫展，工程师抱怨不断，查找bug困难。其实这些都是代码质量差惹的祸。代码质量是研发质量管理的根本，它决定了整个开发团队的开发效率，项目质量，其余监控，告警，日志等手段都只能是过后补偿。本文就如何保证代码质量总结了一些经验和方法，供你们参考。

代码质量自己并无一个特别明确的量化指标，并且根据公司发展的不一样阶段，团队规模的大小不一样，项目性质的不一样等，对代码质量的要求也不尽相同．不过若是项目中出现如下状况时候，就说明代码质量要值得重视了．

添加或修改一个简单功能时，涉及要修改的地方特别多，并且很分散；

代码不可复用：类似的功能没法复用代码，要从新开发；

线上bug频发，排错困难，修复难度大，时间长；

有不少奇怪的代码，代码读不懂，新人没法很快了解代码；

代码中坑特别多，不敢大动，一不当心就踩坑；

以上这些问题，基本上都是代码质量不高致使的，包括代码无注释，无文档，命名差，项目层次结构差，调用关系混乱，处处hardcode，临时解决方案等等。怎么才能时刻保证代码的高质量，避免以上问题发生？固然团队的技术素质很重要，除此以外，还有一些方法可循的．

1. 吹毛求疵般地执行编码规范

严格执行代码编写规范，可使一个项目乃至一个公司的代码具备彻底统一的风格，就像同一我的编写的同样，并且命名良好的变量，函数，类和注释，也无疑能够提升代码的可读性．具体落实到执行层面，能够参照Google的编码规范或者java官方的编码规范，网上能够找到，关键是要严格遵照，而且在code review时，严格要求，没有按照规范的必定要指出而且要求修改．

实际状况每每是虽然你们都知道优秀的代码规范是怎样的，但在具体写代码的过程当中，却执行的差强人意，不少状况是认识上不够重视，以为一个变量或者函数的命名成哪样关系不大，因此不够推敲，注释不少也都不写，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类的封装，都是一种拆分的思想．

7. 重视代码关注细节

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

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

固然并非说框架，工具，架构设计这些方面的学习不重要，关键是有深度，但愿是实践中锻炼得来的，而不是处处看微信公众号，博客得来的。

国内工程师广泛深度不够，作几年技术就转管理或者纯架构设计不写代码了，而国外不同，大龄码农不少，因此国外的优秀开源项目比较多，而国内不多。

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

代码中的不少低级质量问题不须要人工去审查，java开发有不少现成的工具可使用，好比：checkstyle，findbugs, pmd, jacaco, sonar等。

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

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

Sonar Sonar 是一个用于代码质量管理的平台。能够在一个统一的平台上显示管理静态分析，单元测试覆盖率等质量报告。

最后，总结

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