代码质量 ======== .. note:: 灵活性(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 --------------------- .. note:: 软件设计大师 Martin Fowler 曾经说过:“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”代码的可读性应该是评价代码质量最重要的指标之一。代码的可读性在非常大程度上会影响代码的可维护性。 如何评价一段代码的可读性呢:: 我们需要看代码是否符合编码规范、命名是否达意、注释是否详尽、 函数是否长短合适、模块划分是否清晰、是否符合高内聚低耦合等等。 从正面上,我们很难给出一个覆盖所有评价指标的列表。 这也是我们无法量化可读性的原因。 实际上,code review 是一个很好的测验代码可读性的手段:: 如果你的同事可以轻松地读懂你写的代码,那说明你的代码可读性很好; 如果同事在读你的代码时,有很多疑问,那就说明你的代码可读性有待提高了。 3. 可扩展性-extensibility ------------------------- .. note:: 可扩展性也是一个评价代码质量非常重要的标准。它表示我们的代码应对未来需求变化的能力。跟可读性一样,代码是否易扩展也很大程度上决定代码是否易维护。 代码的可扩展性表示:: 我们在不修改或少量修改原有代码的情况下,通过扩展的方式添加新的功能代码 .. note:: 对应设计原则——对修改关闭,对扩展开放 4. 灵活性-flexibility ---------------------- .. note:: 如果一段代码易扩展、易复用或者易用,我们都可以称这段代码写得比较灵活。所以,灵活这个词的含义非常宽泛,很多场景下都可以使用。 5. 简洁性-simplicity -------------------- .. note:: 有一条非常著名的设计原则,你一定听过,那就是 KISS 原则:“Keep It Simple,Stupid”。这个原则说的意思就是,尽量保持代码简单。代码简单、逻辑清晰,也就意味着易读、易维护。我们在编写代码的时候,往往也会把简单、清晰放到首位。 .. note:: 思从深而行从简,真正的高手能云淡风轻地用最简单的方法解决最复杂的问题。这也是一个编程老手跟编程新手的本质区别之一。 6. 可复用性-reusability ----------------------- 可复用性也是一个非常重要的代码评价标准,是很多设计原则、思想、模式等所要达到的最终效果:: 当讲到面向对象特性的时候,我们会讲到继承、多态存在的目的之一,就是为了提高代码的可复用性; 当讲到设计原则的时候,我们会讲到单一职责原则也跟代码的可复用性相关; 当讲到重构技巧的时候,我们会讲到解耦、高内聚、模块化等都能提高代码的可复用性 7. 可测试性-testability ----------------------- 代码可测试性的好坏,能从侧面上非常准确地反应代码质量的好坏:: 代码的可测试性差,比较难写单元测试,那基本上就能说明代码设计得有问题 如何才能写出高质量的代码 ------------------------ :: 面向对象中的继承、多态能让我们写出可复用的代码; 编码规范能让我们写出可读性好的代码; 设计原则中的单一职责、DRY、基于接口而非实现、里式替换原则等, 可以让我们写出可复用、灵活、可读性好、易扩展、易维护的代码; 设计模式可以让我们写出易扩展的代码; 持续重构可以时刻保持代码的可维护性等等 要写出高质量代码:: 我们就需要掌握一些更加细化、更加能落地的编程方法论, 这就包含面向对象设计思想、设计原则、设计模式、编码规范、重构技巧