有一些软件工程师对如何评价代码质量有所认识,如认为好代码是易扩展、易读、 简单、易维护的,等等,但他们对于这些评价的理解往往只停留在表面上,对于诸多更加深入 的问题, “怎么才算可读性好?什么样的代码才算易扩展、易维护?可读、可扩展与可维护 之间有什么关系?
灵活性(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)
代码的可 测试性的高低可以从侧面准确地反映代码质量的高低。代码的可测试性低,难以编写单元测试,那么,基本能够说明代码的设计有问题。