怎么提高代码质量？-来自Google的研发经验总结(2)

除此之外，严格的code review不仅能保证代码的质量，还能形成良好的技术氛围。
4. 开发未动文档先行
编写技术文档对大部分工程师来说都是挺反感的事情。一般来讲在开发某个系统或者重要模块或者功能之前需要先写技术文档，然后发送给同组或者相关同事审查，在审查没有问题的情况下再开发，这样能够事先达成共识，开发出来的东西不至于走样，而且当开发完成之后进行code review的阶段，代码审查者通过阅读开发文档也可以快速的理解代码．
除此之外，文档对于团队和公司来讲都是重要的财富，对于新人加入公司熟悉代码，产品，对于任务的交接等等都很有帮助，而且作为一个规范化的技术团队，技术文档是一种摒弃作坊式开发和个人英雄主义的有效方法，是保证团队有效协作的途径．
不过，有很多工程师提出说不会写技术文档，不知道写什么，希望给一个模板或者目录．我之前曾经想过是否可以给出一个固定的模板，但最后还是放弃了，比较难，难点在于，每个项目侧重点都不一样不容易总结，如果硬要给出一个很宽泛的目录，不具有指导性也没有意义．大体上来讲，文档的内容主要是将做的东西讲清楚，包括出问题背景，解决了什么问题，外部怎么用或调用，内部如何实现，大的架构，关键功能和算法等，以及一些非功能性的考虑。
5. 持续重构，重构，重构
个人比较反对平时不注重代码质量，堆砌烂代码，实在维护不了了就大刀阔斧的重构甚至重写。有时候项目代码太多了，重构很难做到彻底，最后又搞出来一个四不像的怪物，更麻烦了！
优秀的代码或架构不是一开始就能完全设计好的，就像优秀的公司或产品也都是迭代出来的一样的，我们无法100%遇见未来的需求，也没有足够的精力，时间，资源为遥远的未来买单，所以随着系统的演进，重构代码也是不可避免的，虽然上面说了不支持大刀阔斧推到重来式的大重构，但持续的小重构还是比较推崇的，也是时刻保证代码质量防止代码腐化有效手段．简单一句话就是不要等到问题堆得太多了再采取重构，要时刻有人对代码整体负责任，平时没事就改改代码，而不要觉得重构代码就是浪费时间，不务正业！
特别是一些业务开发团队，有时候为了快速完成一个产品或者业务功能，只追求速度，到处hard code，在完全不考虑非功能性需求的情况下，堆砌一些烂代码，这种情况还是比较常见的。不过没关系，等有时间一定要记着重构，不然烂代码越堆越多，总有一天会没人能维护。
6. 项目与团队”微服务化”
只有小项目是可以维护的，大项目是无法维护的．团队人比较少的时候，十几个人的样子，代码量也不多，不超过10万行，怎么开发，怎么管理都没问题，大家互相都了解彼此做的东西，代码质量太差了，大不了重写一遍．但如果是一个极其庞大的项目，几十万行代码，几十个开发维护，那基本上没人能对代码负责了．
所以当项目太大了之后，就需要对代码和团队进行拆分，模块化，大团队拆成几个小团队，大项目拆成几个小项目，这样每个团队每个项目的代码都不至于很多，也不至于出现代码质量太差无法维护的情况，其实很多技术也都体现了这种思想，比如大到soa, 微服务，小到jar, .so等lib模块开发，Class类的封装，都是一种拆分的思想．
7. 重视代码关注细节
以上其他的所有方法都是治标不治本，找到对的人用好对的人，打造优秀的技术文化，才是能一直卓越的根本。有很多工程师比较热衷于学习架构，工具，框架层面的东西，见过很多工程师，还没写三五年代码就转做架构师，不写代码了，到处忽悠，很不好，互联网信息如此透明，不同的人去做同一个项目，其实最后设计出来的架构,功能大约都差不多，最后大家都能把这个系统实现，但有些人做出来的系统，bug很多，性能很差，扩展性也不好，最多能叫个POC。
高手之间的竞争还是在于细节，一个算法够不够优化，数据存取的效率高不高，内存是否够节省等等，这是累积起来决定了一个系统是不是够优秀。
当然并不是说框架，工具，架构设计这些方面的学习不重要，关键是有深度，希望是实践中锻炼得来的，而不是到处看微信公众号，博客得来的。
国内工程师普遍深度不够，做几年技术就转管理或者纯架构设计不写代码了，而国外不一样，大龄码农很多，所以国外的优秀开源项目比较多，而国内很少。

原文转自：https://juejin.im/post/5c88ac2b5188257dda56c87e