如何提高代码质量？你认为好的代码有什么特点？如何审查代码？
代码质量本身并没有一个特别明确的量化指标，而且根据公司发展的不同阶段，团队规模的大小不同，项目性质的不同等，对代码质量的要求也不尽相同．不过如果项目中出现以下情况时候，就说明代码质量要值得重视了．
1.添加或修改一个简单功能时，涉及要修改的地方特别多，而且很分散；
2.代码不可复用：相似的功能无法复用代码，要重新开发；
3.线上bug频发，排错困难，修复难度大，时间长；
4.有很多奇怪的代码，代码读不懂，新人无法很快了解代码；
5代码中坑特别多，不敢大动，一不小心就踩坑；
以上这些问题，基本上都是代码质量不高导致的，包括代码无注释，无文档，命名差，项目层次结构差，调用关系混乱，到处hardcode，临时解决方案等等。怎么才能时刻保证代码的高质量，避免以上问题发生？我认为：
- 开发未动文档先行
编写技术文档对大部分工程师来说都是挺反感的事情。一般来讲在开发某个系统或者重要模块或者功能之前需要先写技术文档，然后发送给同组或者相关同事审查，在审查没有问题的情况下再开发，这样能够事先达成共识，开发出来的东西不至于走样，而且当开发完成之后进行code review的阶段，代码审查者通过阅读开发文档也可以快速的理解代码．
除此之外，文档对于团队和公司来讲都是重要的财富，对于新人加入公司熟悉代码，产品，对于任务的交接等等都很有帮助，而且作为一个规范化的技术团队，技术文档是一种摒弃作坊式开发和个人英雄主义的有效方法，是保证团队有效协作的途径．
大体上来讲，文档的内容主要是将做的东西讲清楚，包括出问题背景，解决了什么问题，外部怎么用或调用，内部如何实现，大的架构，关键功能和算法等，以及一些非功能性的考虑。
2. 较统一一套可执行编码规范
严格执行代码编写规范，而且命名良好的变量，函数，类和注释，也无疑可以提高代码的可读性．具体落实到执行层面上，可以向BAT这类的大公司学习编码规范，代码网上可以找，关键是要严格遵守编码规范，并且在code review时，严格要求，没有按照规范的一定要指出并且要求修改．
3. 适量的Code Review
适量抽出时间code review的好处不仅仅是能够大大提高代码质量，减少代码bug，有了code review，大家就会更认真些．每次code review都是一次案例的剖析，可以帮助初级的工程师培养编码规范，提高编码质量，设计能力甚至于架构能力，反过来，review别人写的好的代码，对自己也是一种学习和提高．
4. 代码重构
优秀的代码或架构不是一开始就能完全设计好的，就像优秀的公司或产品也都是迭代出来的一样的，我们无法100%遇见未来的需求，也没有足够的精力，时间，资源为遥远的未来买单，所以随着系统的演进，重构代码也是不可避免的，虽然上面说了不支持大刀阔斧推到重来式的大重构，但持续的小重构还是比较推崇的，也是时刻保证代码质量防止代码腐化有效手段．简单一句话就是不要等到问题堆得太多了再采取重构，要时刻有人对代码整体负责任，平时没事就发现问题，修改代码，优化逻辑。
5. 重视代码关注细节
对于编写代码，高手之间的竞争还是在于细节，一个算法够不够优化，数据存取的效率高不高，内存是否够节省等等，这是累积起来决定了一个系统是不是够优秀。
6. 工欲善其事必先利其器
每种语言都有比较完善的代码编辑分析/规范处理的工具，所以用合适的工具去编写代码比较方便也省时间。
我认为好的代码的特点：
1. 函数应当遵循：单一抽象层次原则、短小原则和单一职责原则。
2. 当发现一个函数具有以下特征时，需要考虑抽取函数：
1>.过长
2>.嵌套层数过深。
3>.自然分块，需要使用注释描述该程序块
4>.判断条件过于复杂
5>.函数的某些判断分支不断变化
6>.参数过于复杂
7>.逻辑重复
3. 局部变量应当用途单一
4. 新写代码逻辑，应当关注用户场景和类职责划分，不应当上来就考虑我要使用一个什么模式。这样势必会导致过度设计。模式用作应对变化，当后续版本发生变化时，模式用作重构现有代码。
5. 不断重构，保持代码简洁。
审查代码，可以从上面优秀代码的特点和实际项目相结合可以考虑。
