第1章 从哪些维度评判代码质量的好坏？如何具备写出高质量代码的能力？

对于程序员来说，辨别代码写得”好”还是”烂”，是一个非常重要的能力。这也是我们写出好代码的前提。毕竟，如果我们连什么是好代码、什么是烂代码，都分辨不清，又谈何写出好代码呢？

最常用的评价标准有哪几个？
可维护性、可读性、可扩展性、灵活性、简洁性、可复用性、可测试性。

1.可维护性

落实到编码开发，所谓的”维护”无外乎就是修改bug、修改老的代码、添加新的代码之类的工作。所谓”代码易维护”就是指，在不破坏原有代码设计、不引入新的bug的情况下，能够快速地修改或者添加代码。所谓”代码不易维护”就是指，修改或者添加代码需要冒着极大的引入新bug的风险，并且需要花费很长的时间才能完成。

代码的可读性好、简洁、可扩展性好，就会使得代码易维护；相反，就会使得代码不易维护。更细化地讲，如果代码分层清晰、模块化好、高内聚低耦合、遵从基于接口而非实现编程的设计原则等等，那就可能意味着代码易维护。

如果bug容易修复，修改、添加功能能够轻松完成，那我们就可以主观地认为代码对我们来说是易维护的。相反，如果修改一个bug，修改、添加一个功能，需要花费很长的时间，那我们就可以主观地认为代码对我们来说不易维护。

2.可读性

代码的可读性应该是评价代码最重要的指标之一。我们在编写代码的时候，时刻要考虑代码是否易读、易理解。除此之外，代码的可读性在非常大程度上会影响代码的可维护性。毕竟，不管是修改bug，还是修改、添加功能代码，我们首先要做的事情就是读懂代码。代码读不大懂，就很有可能因为考虑不周全，而引入新的bug。

怎么评价代码的可读性呢？

我们需要看代码是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短合适、模块划分是否清晰、是否符合高内聚低耦合等等。

如果你的同事可以轻松地读懂你写的代码，那说明你的代码可读性很好；如果同事在读你的代码时，有很多疑问，那就说明你的代码可读性有待提高了。

3.可扩展性

可扩展性也是评价代码质量非常重要的标准。它表示我们的代码应对未来需求变化的能力。

代码的可扩展性表示，我们在不修改或者少量修改原有代码的情况下，通过扩展的方式添加新的功能代码。说直白点就是，代码预留了一些功能扩展点，你可以把新功能代码，直接插到扩展点上，而不需要添加一个功能而大动干戈，改动大量的原始代码。

4.灵活性

罗列以下几点：

• 当我们添加一个新的功能的时候，原有代码已经预留好了扩展点，我们不需要修改原有的代码，只要在扩展点上添加新的代码即可。这个时候，我们除了可以说代码易扩展，还可以说代码写的好灵活。

• 当我们要实现一个功能的时候，发现原有代码中，已经抽象出了很多底层可以复用的模块、类等代码，我们可以拿来直接使用。这个时候，我们除了可以说代码易复用之外，还可以说代码写的好灵活。

• 当我们使用某组接口的时候，如果这组接口可以应对各种使用场景，满足不同的需求，我们除了可以说接口易用之外，还可以说这个接口设计得好灵活或者代码写的好灵活。

也就是说，如果一段代码易扩展、易复用或者易用，我们都可以称这段代码写得比较灵活。

5.简洁性

KISS原则”Keep It Simple,Stupid”。这个原则说的意思就是，尽量保持代码简单。代码简单、逻辑清晰，也就意味着易读、易维护。我们在编写代码的时候，往往也会把简单、清晰放到首位。

6.可复用性

代码的可复用性可以简单地理解为：尽量减少重复代码的编写，复用已有的代码。

比如，当讲到面向对象特性的时候，我们会讲到继承、多态存在的目标之一，就是为了提高代码的可复用性；当讲到设计原则的时候，单一职责原则也跟代码的可复用性相关；当讲到重构技巧，讲到解耦、高内聚、模块化等都能提高代码的可复用性。

实际上，代码可复用性跟DRY(Dont Repeat Yourself)这条设计原则的关系挺紧密的。

7.可测试性

代码可测试性的好坏，能从侧面上非常准确地反应代码质量的好坏。代码的可测试性差，比较难写单元测试，那基本上就能说明代码设计得有问题。

如何才能写出高质量的代码？

上面列出了七点高质量代码的评价标准，对于如何写出高质量代码这个问题，也如同在问：如何写出易维护、易读、易扩展、灵活、简洁、可复用、可测试的代码。

这个就需要我们掌握一些更加细化、更加能落地的编程方法论，包括面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等。

比如，面向对象中的继承、多态能让我们写出可复用的代码；编码规范能让我们写出可读性好的代码；设计原则中的单一职责、DRY、基于接口而非实现、里氏替换原则等，可以让我们写出可复用、灵活、可读性好、易扩展、易维护的代码；设计模式可以让我们写出易扩展的代码；持续重构可以时刻保持代码的可维护性等等。