KISS(保持简单傻瓜)
大部分系统如果能保持简单而不是复杂时会工作得很好。因为：
- 更少的代码只花费更少的时间编写，有更少的错误，更容易修改。
- 简单是终极的成熟。
- 一点都不能移除时才是完美，而不是在没有什么可增加时
最近遇到一个项目，项目不大，但是用的技术，不得不说都很高端的，高端意味着维护困难，我觉得能用一个团队一个或者多个项目搞定的事情，这个项目用了我都不知道好多的人，拆分了不知道多少个子业务。但是公司有钱，这种，就另说把。
YAGNI
YANGNI是“你不需要它”的意思，直到你需要时再实现。因为：
- 任何为明天所需要的功能而实现编程工作，意味着失去了为当前功能进行迭代的努力。
- 它会导致代码膨胀；软件变得更大更复杂。
如何做？
当你真正需要的时候再去实现，而不是你预想你会需要他们时就去实现。这点很重要，在工作中与遇到很多程序员相反的态度，包括我自己。近期一个人负责了一个项目，才知道这点真的很重要，对于维护来说简直就是灾难。
做只要能运行的事情
如果我们只是针对问题工作，针对问题的真正实施过程才能效率最大化。因此，经常问你自己：什么是让它工作的最简单事情？
分离关注
分离的关注是一个设计原则，将计算机程序分离成不同部分，使得每个部分解决了一个单独关注点。例如，应用程序的业务逻辑是一个关注点，用户界面是另一个关注点。改变用户界面不应该要求更改业务逻辑，反之亦然。
- 简化软件应用程序的开发和维护。
- 当关注是分离的，单独的部分可以重复使用，以及独立开发和更新。
将程序功能切分成不同模块，尽可能相互重叠比较小。
让事情DRY
每一个知识都必须有一个单一的、明确的、在一个系统内的权威表示。不要重复，需要干脆。
在一个程序中的每一个重要的功能都应该在源代码中的一个地方实现。
- 重复（无意或有目的的重复）可能会导致维护恶梦，不可能的因式分解和逻辑矛盾。
- 任何一个系统的任何一个元素的修改不需要在其他逻辑上修改无关的元素
- 逻辑上相关的所有元素的变化，必须可以是可预见的和均匀的，这样才能保持同步。
如何做？
- 将业务规则、长表达式，if语句、数学公式和元数据等各自放在一个地方
- 确定表示你系统中每个知识片段的唯一性，防止重复，明确来源和使用该源码有关知识如代码文档测试和适用情况。
为维护者编码
维修是迄今为止任何项目中最昂贵的阶段。
- 成为一个维护者
- 编码时，要想象这个代码的最终维护者会像神经病一样发疯地找到你。。。
- 代码和注释遵循后来者能够很高兴地阅读和学习
- .
- 使用 .
就像上面说的样，当你资历越来越老的时候，你就会发现这个可能是项目初期重点之一，就我最近一个人负责的那个项目，真是把我折腾惨了，毕竟也才两年工作经验遇到的坑太少了，算是学到了。
避免过早性能优化
- 瓶颈在哪里是未知的
- 优化后，可能更难以阅读和维护
怎么做？
- 直到你需要时再优化，也只有在性能测试后发现优化瓶颈所在。
最小化耦合
- 一个模块的改变通常会引起其他模块的连锁反应.
- 模块组件因为模块之间的依赖会需要更多努力和时间编写维护。
- 一个特定的模块可能会更难重用或测试，因为所依赖的模块也必须加入重用或测试。
- 开发人员可能害怕修改代码，因为他们不知道可能会发生什么影响。
怎么办？
- 消除 尽量减少和降低不要的复杂度
- 通过隐藏实现细节，降低耦合
- 应用 .
得墨忒耳定律（迪米特法则）
不要和陌生人讲话
- 一个对象的方法调用其他方法实际就是发生了紧耦合
- 太多实现细节暴露在外面
怎么办？一个对象的方法调用其他方法时，必须遵循下面迪米特法则：
- 可以调用对象自己的方法
- 自己方法的参数的方法
- 在方法内部被创建的任何对象
- 该对象任何直接属性或字段
用组合而不是继承
- 类之间的耦合少。
- 用继承，子类容易作出假设，也就是父类的很多属性状态可能会被子类改变，虽然可能在一起运行，但是阅读不方便，并打破LSP
怎么办？
- 根据LSP（可置换性）决定什么时候继承
- 当有"has a"关系时用组合，表达“is a”时使用继承
正交性
正交性的基本思想是，不相关的东西在概念上不应该在一个系统中。
它与简单性相关联；设计的正交性越正交，例外性越少。这使得它更容易在编程语言中学习、读和写程序代码。正交特征的意义是独立于上下文的，关键参数是对称性和一致性。
最大聚合
一个单一的模块/组件的凝聚度是它形成一个有意义的职责单元的程度，更高的凝聚度意味更好。
- 增加理解模块的难度。
- 增加在维护系统的困难，因为在领域逻辑变化会影响多个模块，因为在一个模块的变化，会增加相关模块的变化，不如将它们放在一个模块中。
- 增加重用一个模块的困难，因为大多数应用程序不需要由模块提供的随机操作集。
怎么办？将共享同一职责的相关功能放在一个块儿。
Liskov替换原则
LSP是关于对象行为的预期，程序中的对象在不改变该程序的正确性的情况下，可以用他们的子类型实例来替换。
开闭原则
软件类实体应该对拓展开放，对修改闭合。通过降低对现存代码的修改，提高可维护性和稳定性。
怎么办?
- 编写可以被拓展的类。
- 只暴露可能需要拓展的地方，其他都隐藏起来。
单一职责
每个类应该有单一职责，职责应该被类封装。所有职责混合在一个模块或类中会导致维护改变很难。
Curly法则
为任何特定的代码选择一个单一的、明确的目标，做一件事。
童子军规则
童子军规则规定，我们应该总是把代码清除比我们发现时更干净。
总结：The simpler the better