Design Patterns ｜ 02 什么样的代码是好代码
目录
01 – 什么是好的代码？
对开发人员来说，辨别代码的“好”和“烂”，是个非常重要的能力，这也是我们写出好代码的前提。
那什么是好的代码，我们应该从哪些维度评判代码质量的高低呢？
答案是：很难通过某（几）个词汇来全面地评价代码质量。
“评价”这个词本身就有很强的主观性，每个人的标准都不尽一致。但不可否认的是，越有经验的工程师，给出的评价也就越准确。
02 – 评价代码的标准有哪些
2.1 可维护性（maintainability）
“维护”，就是修改 bug、修改老代码、添加新代码之类的工作。
- “代码易维护”，就是在不破坏原有代码设计、不引入新 bug 的情况下，能够快速修改或者添加代码。
- “代码不易维护”，就是修改或者添加代码时很可能引入新的 bug，并且需要花费很长的时间才能完成。
大多数项目中，维护代码的时间要远多于编写代码的时间，所以代码的可维护性非常重要。
影响代码的可维护性的因素有很多，比如：
代码的分层是否清晰，模块化是否良好，模块间耦合性是否足够低（要高内聚、低耦合）；
项目代码量的多少，业务的复杂程度，使用到的技术的复杂程度；
另外，各类过程文档的编写、团队成员的开发水平等因素也会影响代码的可维护性。
2.2 可读性（readability）
首先，代码被阅读的次数要远远超过被编写、修改的次数，读不懂代码，就很难安全地添加新功能、修复旧 bug。
代码的可读性，与代码是否符合编码规范、代码的命名（包括类、函数、变量等）是否达意、注释是否详尽、函数是否长短合适、模块划分是否清晰等因素有关。
影响代码的可维护性的因素有很多，比如：
Code Review（代码审查）是个很好的测验代码可读性的方法。
如果你的同事可以轻松读懂你写的代码，说明你的代码可读性很好；
如果其他人在读你的代码时，有很多疑问，说明你的代码可读性并不高。
2.3 可扩展性（extensibility）
可扩展性表示代码应对未来需求变化的能力。
如果原有的代码已经预留好了扩展点（比如原代码中抽象了很多底层可以复用的模块），我们在修改很少代码的情况下，添加新的功能。
这个时候，就可以说代码的可扩展性好，也可以说成代码的灵活性（flexibility）好。
影响代码的可维护性的因素有很多，比如：
代码的可读性和可扩展性，在很大程度上决定了代码是否有良好的维护性。
2.4 简洁性（simplicity）
用最简单的方法解决最复杂的问题，能做到这一点的，都是真正的大牛。
程序开发中有个很有名的 KISS 原则：“Keep It Simple, Stupid”，就是说要尽量保持代码简单，甚至于傻瓜化，这其实也意味着代码易读、易维护。
2.5 可复用性（reusability）
开发过程中，要多复用已有的代码，尽力避免堆砌重复（相似）的代码。
与可复用性相关的设计原则和实践经验有：
与 KISS 原则齐名的 DRY（Don’t Repeat Yourself）原则，强调的就是要提高代码的可复用性；
有面向对象编程基础的同学，应该都知道继承、多态存在的目的之一，就是提高代码的可复用性；
单一职责原则、解耦、高内聚、模块化等实践经验都能提高代码的可复用性。
2.6 可测试性（testability）
这个评判维度比较少提及，但却是非常重要的代码质量评价标准。
为了降低线上的故障率，我们的代码需要通过测试环节的检验。可测试性良好的代码有利于编写单元测试，有利于我们在测试环节更全面地发现问题、更快地定位到是哪些代码产生了这些问题。
可测试性高的代码大多有这些特征：
职责单一；
输入明确（可控制）；
输出清晰（可预测）；
运算状态（一般是错误状态）可见；……
03 – 本篇总结
设计问题没有标准答案，关键是我们要有自己的思考：
为什么有这种设计原则、思想或模式？
它能解决什么问题？有哪些应用场景？
该如何权衡、恰当地在项目中应用？
同时要认识到，上述评价维度 不是完全独立 的，有些具有包含关系，也有的会互相影响。比如：
代码的可读性好、可扩展性好，就意味着代码的可维护性好；
有些代码的可扩展性和可复用性好，抽象出了很多接口、类和方法，但却又导致代码的可读性和简洁性下降。
现在，我们摸清了好代码的样子，也知道了好代码的常见评判标准，接下来我们就要学习各类设计原则和设计思想了哦。
开始期待吧 🙂
参考资料：
极客时间-王争《设计模式之美》
版权声明
出处: 博客园 瘦风的博客(https://www.cnblogs.com/shoufeng)
感谢阅读, 右侧导航栏有「瘦风的南墙」公众号二维码，输出更及时、更体系，欢迎扫码关注