1、代码质量评价标准
-
可维护性（maintainability）
“代码易维护”就是指，在不破坏原有代码设计、不引入新的 bug 的情况下，能够快速地修改或者添加代码。
“代码不易维护”就是指，修改或者添加代码需要冒着极大的引入新 bug 的风险，并且需要花费很长的时间才能完成。
-
可读性（readability）
任何傻瓜都会编写计算机能理解的代码。好的程序员能够编写人能够理解的代码。
-
可扩展性（extensibility）
代码的可扩展性表示，我们在不修改或少量修改原有代码的情况下，通过扩展的方式添加新的功能代码。
-
灵活性（flexibility）
如果一段代码易扩展、易复用或者易用，我们都可以称这段代码写得比较灵活。
-
简洁性（simplicity）
尽量保持代码简单。代码简单、逻辑清晰，也就意味着易读、易维护。我们在编写代码的时候，往往也会把简单、清晰放到首位。
-
可复用性（reusability）
尽量减少重复代码的编写，复用已有的代码。
-
可测试性（testability）
代码可测试性的好坏，能从侧面上非常准确地反应代码质量的好坏。代码的可测试性差，比较难写单元测试，那基本上就能说明代码设计得有问题。
其中比较常用的三个标准是：可维护性、可读性、可扩展性。
2、设计原则
-
SRP 单一职责原则
一个类或者模块只负责完成一个职责（或者功能）
-
OCP 开闭原则
软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”。
-
LSP 里式替换原则
- 子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。
- 子类在设计的时候，要遵守父类的行为约定（或者叫协议）。父类定义了函数的行为约定，那子类可以改变函数的内部实现逻辑，但不能改变函数原有的行为约定。这里的行为约定包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明。
-
ISP 接口隔离原则
客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。
-
DIP 依赖倒置原则
高层模块（high-level modules）不要依赖低层模块（low-level）。高层模块和低层模块应该通过抽象（abstractions）来互相依赖。除此之外，抽象（abstractions）不要依赖具体实现细节（details），具体实现细节（details）依赖抽象（abstractions）。
-
DRY 原则、KISS 原则、YAGNI 原则、LOD 法则
-
DRY
不要写重复的代码。
-
KISS
尽量保持简单
-
YAGNI
不要去设计当前用不到的功能；不要去编写当前用不到的代码。核心思想就是：不要做过度设计。
-
LOD
不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。
-
