1. Don’t Repeat Yourself (DRY)
- 对重复代码进行公共方法提取，进行功能抽象、模板提取和功能最小化等操作。
- 若在项目中很多的重复代码，意味着程序缺乏设计和抽象，这样的代码显得臃肿，不够简洁、清晰，容易造成改写扩散，不易维护。
2.Keep It Simple, Stupid (KISS)
- 万物至简，例如计算机的二进制，简单意味着易用，易理解、易维护。
- what is simple? one is simple.
- 编写的代码要简介、优雅、抽象合理、易于理解。
3.Program to an interface, not an implementation
- 面向接口编程而不是面向实现编程，参考JAVA集合框架的设计理念。
- 接口是约束、契约、对外交流的官方语言
4.Command-Query Separation (CQS) – 命令-查询分离原则
- 查询接口不改变对象的状态，命令接口改变对象的状态
- 一个接口中不要同事混用查询和命令，这样会导致对象状态处于不稳定状态，让对象处于混乱状态
- 一个反例就是有人竟然在bean的get方法中做一些乱七八糟的操作，防不胜防
5.You Ain’t Gonna Need It (YAGNI)
- 不要过度设计，因为你可能没等到扩展，软件已经到了生命周期的末端，或者软件就没有得到商业的成功，这些都是没有意义的。
- 满足当下，适当的保留未来可预期的扩展点即可（需要理性分析）
6.Law of Demeter （LOD）– 迪米特法则
- 最少知道原则
- 不要有Feature Envy(依恋情结），管好自己就好，不要过多的关注别人。
7.面向对象的S.O.L.I.D 原则(SOLID（单一功能、开闭原则、里氏替换、接口隔离以及依赖反转）)
-
Single Responsibility Principle (SRP) – 职责单一原则
一个类只干一件事情，要专注而不是融合，反例就是一个Utils工具类中有若干不相干的操作 -
Open/Closed Principle (OCP) – 开闭原则
对扩展是开放的，而对修改是封闭的
对扩展开放意味着程序有扩展点，有新功能时能够在很少改动的情况下完成
对修改封闭意味着程序内部的修改不会影响对外的呈现，可以理解为面向接口编程而不是实现
应该以插件式的方式来编写类和模块,不改写类而是增加类 -
Liskov substitution principle (LSP) – 里氏代换原则
子类必须能够替换成它们的基类。即：子类应该可以替换任何基类能够出现的地方，并且经过替换以后，代码还能正常工作。 -
Interface Segregation Principle (ISP) – 接口隔离原则
要把一个功能比较多且杂的接口类拆分为几个相互独立的接口类，这样方便这些相互隔离接口的复用，复杂接口类不利于子类的编写，只有简单的接口类才方便编写子类
正面例子Comparable、Serializable等接口类只有一个方法。 -
Dependency Inversion Principle (DIP) – 依赖倒置原则
高层模块不应该依赖于低层模块的实现，而是依赖于高层抽象
一个例子就是：找人解决问题先找领导，让领导安排到底找手下的那个人解决问题。你对接的是领导而不是具体的哪个成员。
8. Common Closure Principle（CCP）– 共同封闭原则
- 若代码引发了修改，则修改涉及到的类应该限制在一个包中，不应该扩散到其他包中，要对修改收敛。
9. High Cohesion & Low/Loose coupling & – 高内聚， 低耦合
10. Convention over Configuration（CoC）– 惯例优于配置原则
- 将一些公认的配置方式和信息作为内部缺省的规则来使用
- 正面例子：Maven、Gradle，Spring Boot。
11. 标准化（形成标准、规范、流程等）
12. 类、包等不循环依赖
13.做有价值的事情，不要把自己当作使蛮力的牲口
参考文献
