日常编码还是要多注意！
破窗理论
破窗理论，原义指窗户破损了，建筑无人照管，人们放任窗户继续破损，最终自己也参与破坏活动，在外墙上涂鸦，任垃圾堆积，最后走向倾颓。
破窗理论在实际中非常容易出现，往往第一个人的代码写的不好，第二个人就会有类似“反正他已经写成这样了，那我也只能这样了”的思想，导致代码越维护越冗杂，最后一刻轰然坍塌，变成无人想去维护的垃圾。
哈哈，确实如此，在编码过程中深有体会，但是不知道用这个名词表示，新概念GET！
代码原则
在现代化的前端开发中，有很多自动化工具可以帮助我们写出规范的代码，如eslint，tslint等各种辅助校验工具，知名的规范如google规范、airbnb规范等等也从各个细节方面约束，帮助我们形成合理规范的代码风格。
下面列出一系列开发过程中需要时刻注意的原则，按照重要程度优先级排列。
DRY
DRY(Don’t Repeat Yourself)，很多设计模式，包括面向对象本身，都是在这条原则上做努力。
DRY顾名思义，是指“不要重复自己”，它实际上强调了一个抽象性原则，如果同样或类似的代码片段出现了两次以上，那么应该将它抽象成一个通用方法或文件，在需要使用的地方去依赖引入，确保在改动的时候，只需调整一处，所有的地方都改变过来，而不是到每个地方去找到相应的代码来修改。
SRP
SRP(Single Responsibility Principle)，单一职责，在面向对象的编程中，认为类应该具有单一职责，一个类的改变动机应当只有一个。
对于前端开发来说，最需要贯彻的思想是函数应当保持单一职责
- 一个函数应当只做一件事，这样一来是保证函数的可复用性，更单一的函数有更强的复用性，
- 二来可以让整体的代码框架更加清晰，细节都封装在一个个小函数中。
- 另外一点也和单一职责有关，就是无副作用的函数，也称纯函数，我们应当尽量保证纯函数的数量，非纯函数是不可避免的，但应当尽量减少它。
LKP
LKP(Least Knowledge Principle)，最小知识原则，又称“迪米特”法则，也就是说，一个对象应该对另一个对象有最少的了解，你内部如何复杂都没关系，我只关心调用的地方。
保持暴露接口的简洁易用性也是API设计的通用规则。对于一个模块而言，暴露出去的方法往往会被很多模块重复调用。我们有必要让自己和他人可以轻松知道，这个模块哪些是内部方法，哪些是暴露出去的方法，比如我们可以在方法前添加_下划线表示是内部方法，大胆重构不用怕是吧，随着前端模块化时代的到来，不这么标识我们也已经可以轻松知道了。
其他
上述偏向于代码的可维护性，接下来谈谈代码可读性
- 可读性基本定义：对一些编码原则和方案进行取舍时，如果都占理，那就看谁可能性更强
- 有意义的名称
- 适当的注释维护