单一职责原则（SRP）
一个对象（方法/类）只做一件事。
如果一个方法承担了过多的功能，那么在需求的变迁过程中，需要改写这个方法的可能性就越大。
如果随着需求的变化，有两个职责总是同时变化，那就不必分离他们。比如在 ajax 请求的时候，创建xhr对象和发送xhr请求几乎总是在一起的，那么创建xhr对象的职责和发送xhr请求的职责就没有必要分开。
优点是降低了单个类或者对象的复杂度，按照职责把对象分解成更小的粒度，这有助于代码的复用，也有利于进行单元测试。
缺点是会增加编写代码的复杂度。当我们按照职责把对象分解成更小的粒度之后，实际上也增大了这些对象之间相互联系的难度。
相关文章：
最少知识原则（LKP）
也叫迪米特法则，最小可用原则
尽量减少对象之间的交互。
常见的做法是引入一个第三者对象，来承担这些对象之间的通信作用。如果一些对象需要向另一些对象发起请求，可以通过第三者对象来转发这些请求。
相关文章：
- 中介者模式
- 外观模式
开放封闭原则（OCP）
核心：在不改动源码的基础上，程序的功能是可以拓展或者修改的。
最简单粗暴的方法就是找出程序中将要发生变化的地方，然后把变化封装起来。
回调函数是一种特殊的挂钩。我们可以把一部分易于变化的逻辑封装在回调函数里，然后把回调函数当作参数传入一个稳定和封闭的函数中。
- 挑选出最容易发生变化的地方，然后构造抽象来封闭这些变化。
- 在不可避免修改的时候，尽量修改那些相对容易修改的地方。拿一个开源库来说，修改配置文件，总比修改源代码来得简单。
相关文章：
代码重构
判断是否需要重构的标准
- 迭代效率。代效率变低了，比如代码的研发效率越来越低，严重阻碍了它的迭代速度。
- 稳定性。开发者修改一 Bug 引出了多个新 Bug，代码变得很复杂了。
- 扩展性。扩展性不足，性能无法满足要求，比如做大型运营活动时，单体无法满足需求，企业就需要做一些分布式的改造，把主链路和分支链路分开，做更好的扩展性和弹性。
