分享一下啊

有一些软件工程师对如何评价代码质量有所认识，如认为好代码是易扩展、易读、 简单、易维护的，等等，但他们对于这些评价的理解往往只停留在表面上，对于诸多更加深入 的问题， “怎么才算可读性好？什么样的代码才算易扩展、易维护？可读、可扩展与可维护 之间有什么关系？

灵活性（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）等

对于代码质量，我们也需要 要综合多种因素进行评价，不应该从单一的角度去评价。

软件工程师的经验越丰富，给出的评价往往越准确。形成对比的是，资历较浅的 软件工程师常常觉得没有一个可量化的评价标准作为参考，很难准确判断一段代码的质量。如 如果无法辨别代码写得好或坏，那么，即使写再多的代码，编码能力也可能没有太大提高。

选了7 个常用且重要的评价标准来详细讲解，包括可 维护性、可读性、可扩展性、灵活性、简洁性、可复用性和可测试性。

一：可维护性（maintainability）

可维护性是一个难以量化、偏向对代码整体进行评价的标准，它类似之前提到的 “好”“坏”“优雅”之类的笼统评价。代码的可维护性高低是由很多因素共同作用的结果。代 码简洁、可读性好、可扩展性好，往往就会使得代码更易维护。更深入地讲，如果代码分层清 晰、模块化程度高、高内聚低耦合、遵守基于接口而非实现编程的设计原则等，就可能意味着 代码易维护。

二：可读性（readability）

代码的可读性如此重要，在编写代码的时候，我们要时刻考虑代码是否易读、易理解。代 码的可读性在很大程度上会影响代码的可维护性，因为无论是修复 bug 还是添加 / 修改功能代 码，我们首先要读懂代码，查看代码是否符合代码规范，如命名是否达意、注释是否详尽、函数长度是否合 适、模块划分是否清晰， 以及代码是否“高内聚、低耦合”等。

三：可扩展性（extensibility）

代码的可扩展性是指在不修改或少量修改原有代码的情况下，能够通过扩展方式添加新功能 能代码。可以把新 功能代码直接插入扩展点，而不会因为添加新的功能代码而改动大量的原始代码。可扩展性也 是评价代码质量的重要标准。

四：灵活性（flexibility）

很多人用“灵活”描述代码质量，但实际上，“灵活”是一个抽象的评价标准，给“灵活”下定义是很难的。不过，我们可以想一下

A：当我们添加新功能代码时，由于原有代码中已经预留了扩展点

B：当我们要实现一个功能时，如果原有代码中已经抽象出了很多位于底层且可复用的模 块、类等，那么我们可以直接使用。

C：当我们使用某个类时，如果这个类可以应对多种使用场景，满足多种不同需求，那么， 我们除可以说这个类易用以外，还可以说这个类设计得很灵活或代码写得很灵活。

五：简洁性（simplicity）

代码简单、逻辑清晰往往意味着什么 码易读、易维护。在编写代码的时候，我们往往会把“简单、清晰”原则放到首位，实际上，思从深而行从简，真正的 编程高手往往能用简单的方法解决复杂的问题。

六：可复用性（reusability）

我们可以将代码的可复用性简单地理解为“尽量减少重复代码的编写，复用已有代码”。可复用性是一个重要的代码评价指标 准，也是很多设计原则、设计思想和设计模式等所要实现的最终效果。实际上，代码的可复用性与 DRY（Don’t Repeat Yourself）原则的关系紧密。

七：可测试性（testability）

代码的可 测试性的高低可以从侧面准确地反映代码质量的高低。代码的可测试性低，难以编写单元测试，那么，基本能够说明代码的设计有问题。