# 设计模式之美 [设计模式之美 (geekbang.org)](https://time.geekbang.org/column/intro/100039001?tab=catalog) ## 评价代码 从一下几个角度： 可维护性、可读性、可扩展性、灵活性、简洁性（简单、复杂）、可复用性、可测试性 ### 可维护性 如果 bug 容易修复，修改、添加功能能够轻松完成，那我们就可以主观地认为代码对我们来说易维护。相反，如果修改一个 bug，修改、添加一个功能，需要花费很长的时间，那我们就可以主观地认为代码对我们来说不易维护。 ### 可读性 >Google 内部甚至专门有个认证就叫作 Readability。只有拿到这个认证的工程师，才有资格在 code review 的时候，批准别人提交代码。可见代码的可读性有多重要，毕竟，代码被阅读的次数远远超过被编写和执行的次数。 我们需要看代码是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短合适、模块划分是否清晰、是否符合高内聚低耦合等等。 如果你的同事可以轻松地读懂你写的代码，那说明你的代码可读性很好；如果同事在读你的代码时，有很多疑问，那就说明你的代码可读性有待提高了。 ### 可扩展性 主要于开放闭合有关。对修改关闭，对扩展开放。 ### 灵活性 一种综合性质的评价，结合可维护，可扩展来评价。 ### 简洁性 KISS 原则：“Keep It Simple，Stupid”。这个原则说的意思就是，尽量保持代码简单。代码简单、逻辑清晰，也就意味着易读、易维护。我们在编写代码的时候，往往也会把简单、清晰放到首位。 ### 可复用性 尽量减少重复代码的编写，复用已有的代码。 ### 可测试性 相对于前面六个评价标准，代码的可测试性是一个相对较少被提及，但又非常重要的代码质量评价标准。代码可测试性的好坏，能从侧面上非常准确地反应代码质量的好坏。代码的可测试性差，比较难写单元测试，那基本上就能说明代码设计得有问题。