代码质量¶
备注
灵活性（flexibility）、可扩展性（extensibility）、可维护性（maintainability）、可读性（readability）、可理解性（understandability）、易修改性（changeability）、可复用（reusability）、可测试性（testability）、模块化（modularity）、高内聚低耦合（high cohesion loose coupling）、高效（high effciency）、高性能（high performance）、安全性（security）、兼容性（compatibility）、易用性（usability）、整洁（clean）、清晰（clarity）、简单（simple）、直接（straightforward）、少即是多（less code is more）、文档详尽（well-documented）、分层清晰（well-layered）、正确性（correctness、bug free）、健壮性（robustness）、鲁棒性（robustness）、可用性（reliability）、可伸缩性（scalability）、稳定性（stability）、优雅（elegant）、好（good）、坏（bad）… …
分类:
有些词语过于笼统、抽象，比较偏向对于整体的描述，比如优雅、好、坏、整洁、清晰等；
有些过于细节、偏重方法论，比如模块化、高内聚低耦合、文档详尽、分层清晰等；
有些可能并不仅仅局限于编码，跟架构设计等也有关系，比如可伸缩性、可用性、稳定性等。
最常用的、最重要的评价标准:
可维护性:
可读性、可扩展性、灵活性、简洁性（简单、复杂）、可复用性、可测试性
1. 可维护性-maintainability¶
定义:
代码易维护: 在不破坏原有代码设计、不引入新的 bug 的情况下，能够快速地修改或者添加代码
代码不易维护: 修改或者添加代码需要冒着极大的引入新 bug 的风险，并且需要花费很长的时间才能完成
说明:
对于一个项目来说，维护代码的时间远远大于编写代码的时间。
工程师大部分的时间可能都是花在修 bug、改老的功能逻辑、添加一些新的功能逻辑之类的工作上。
所以，代码的可维护性就显得格外重要。
可维护性也是一个很难量化、偏向对代码整体的评价标准，它有点类似之前提到的 “好”“坏”“优雅” 之类的笼统评价:
代码的可维护性是由很多因素协同作用的结果。
代码的可读性好、简洁、可扩展性好，就会使得代码易维护；相反，就会使得代码不易维护。
更细化讲，代码分层清晰、模块化好、高内聚低耦合、遵从基于接口而非实现编程的设计原则等等，就可能意味着代码易维护
除此之外，代码的易维护性还跟:
项目代码量的多少、业务的复杂程度、利用到的技术的复杂程度、
文档是否全面、团队成员的开发水平等诸多因素有关。
从侧面上给出一个比较主观但又比较准确的感受:
如果 bug 容易修复，修改、添加功能能够轻松完成，那我们就可以主观地认为代码对我们来说易维护。
相反，如果修改一个 bug，修改、添加一个功能，需要花费很长的时间，那我们就可以主观地认为代码对我们来说不易维护。
疑问:
太主观了吧？
没错，是否易维护本来就是针对维护的人来说的。
不同水平的人对于同一份代码的维护能力并不是相同的。
对于同样一个系统，熟悉它的资深工程师会觉得代码的可维护性还不错，
而一些新人因为不熟悉代码，修改 bug、修改添加代码要花费很长的时间，就有可能会觉得代码的可维护性不那么好。
这实际上也印证了我们之前的观点：代码质量的评价有很强的主观性。
2. 可读性-readability¶
备注
软件设计大师 Martin Fowler 曾经说过：“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”代码的可读性应该是评价代码质量最重要的指标之一。代码的可读性在非常大程度上会影响代码的可维护性。
如何评价一段代码的可读性呢:
我们需要看代码是否符合编码规范、命名是否达意、注释是否详尽、
函数是否长短合适、模块划分是否清晰、是否符合高内聚低耦合等等。
从正面上，我们很难给出一个覆盖所有评价指标的列表。
这也是我们无法量化可读性的原因。
实际上，code review 是一个很好的测验代码可读性的手段:
如果你的同事可以轻松地读懂你写的代码，那说明你的代码可读性很好；
如果同事在读你的代码时，有很多疑问，那就说明你的代码可读性有待提高了。
3. 可扩展性-extensibility¶
备注
可扩展性也是一个评价代码质量非常重要的标准。它表示我们的代码应对未来需求变化的能力。跟可读性一样，代码是否易扩展也很大程度上决定代码是否易维护。
代码的可扩展性表示:
我们在不修改或少量修改原有代码的情况下，通过扩展的方式添加新的功能代码
备注
对应设计原则——对修改关闭，对扩展开放
4. 灵活性-flexibility¶
备注
如果一段代码易扩展、易复用或者易用，我们都可以称这段代码写得比较灵活。所以，灵活这个词的含义非常宽泛，很多场景下都可以使用。
5. 简洁性-simplicity¶
备注
有一条非常著名的设计原则，你一定听过，那就是 KISS 原则：“Keep It Simple，Stupid”。这个原则说的意思就是，尽量保持代码简单。代码简单、逻辑清晰，也就意味着易读、易维护。我们在编写代码的时候，往往也会把简单、清晰放到首位。
备注
思从深而行从简，真正的高手能云淡风轻地用最简单的方法解决最复杂的问题。这也是一个编程老手跟编程新手的本质区别之一。
6. 可复用性-reusability¶
可复用性也是一个非常重要的代码评价标准，是很多设计原则、思想、模式等所要达到的最终效果:
当讲到面向对象特性的时候，我们会讲到继承、多态存在的目的之一，就是为了提高代码的可复用性；
当讲到设计原则的时候，我们会讲到单一职责原则也跟代码的可复用性相关；
当讲到重构技巧的时候，我们会讲到解耦、高内聚、模块化等都能提高代码的可复用性
7. 可测试性-testability¶
代码可测试性的好坏，能从侧面上非常准确地反应代码质量的好坏:
代码的可测试性差，比较难写单元测试，那基本上就能说明代码设计得有问题
如何才能写出高质量的代码¶
面向对象中的继承、多态能让我们写出可复用的代码；
编码规范能让我们写出可读性好的代码；
设计原则中的单一职责、DRY、基于接口而非实现、里式替换原则等，
可以让我们写出可复用、灵活、可读性好、易扩展、易维护的代码；
设计模式可以让我们写出易扩展的代码；
持续重构可以时刻保持代码的可维护性等等
要写出高质量代码:
我们就需要掌握一些更加细化、更加能落地的编程方法论，
这就包含面向对象设计思想、设计原则、设计模式、编码规范、重构技巧