之前看有关对于编程规范的一个讨论，一位前谷歌员工觉得编程原则 总共涉及 面向对象、设计原则、设计模式、编程规范和代码重构
其中面向对象，或者前端现在流行的函数式编程
- 其实思考他们的关系在我看来，依据自顶向下的思考方式
- 编程思想作为最底层的操作系统
- 设计原则是代码层面的最高抽象
- 而设计模式是设计原则的具体体现
- 而编程规范则是非常的具体执行
- 而代码重构是一个贯彻于业务中的始终
层层深入。
其实和日常开发相关的，到是编程规范居多 四格缩进还是两格缩进？
使用两格缩进，这样可以节省空间。特别是在代码嵌套层次比较深的 情况下，累计缩进较多的话，容易导致一个语句被折成两行，影响代码可读性。
函数设计要职责单一
- 其实这个就是基于设计原则：单一职责了
那么针对于这个函数参数过多的一个情况要学会抽象封装对象
勿用函数参数来控制逻辑
- 经常会在函数中大量书写当参数为null 或者undefined 一种逻辑，还有当这个为fasle的时候，或者为true一段逻辑，其实这个就已经违背了这个单一职责了把两种逻辑抽象封装为两个函数
如何真正理解这个单一职责SRP
定义
一个类或者模块只负责完成一个职责（或者功能）。 什么时候用 当类或者方法内部逻辑存在两种相互独立的逻辑就要拆开 不要设计大而全的类，要设计粒度小、功能单一的 类。单一职责原则是为了实现代码高内聚、低耦合，提高代码的复用性 类中的代码行数、函数或者属性过多；读性、可维护性。 但是凡是过犹不及，如果拆分的过于细致，那么也会加大理解阅读成本
《架构整洁之道》这样阐述这个SRP 任何一个软件模块都应该只对一个用户(User)或系统利益相关者(Stakeholder)负责。 在组件层面，我们可以将其称为共同闭包原则(Common Closure Principle)，在软件架构层面，它则是用于奠定架构边界的变更轴心(Axis of Change)。 就是组件之内只要是共同为一个功能负责就应该放在在一起，同时对于这个变更轴心，就是指单一职责直接影响的时候整个架构变化的一个范围
学会使用解释性变量 常量取代魔法数字。
