破窗效应是犯罪心理学的一个理论，指如果一个建筑，当出现小量破窗的时候，会诱发更多的人为破坏。如果一个建筑出现破窗的时候及时修复，会受到更少破坏。
我们是否有这样的经历，当接手一个代码质量较差的项目，例如一个函数有上百行的代码，函数里有大量的if else，如果让你增加一个功能，你更倾向于直接在目标函数上加入你的改动代码，而不是通读该方法，再进行封装修改呢。
其实这样的修改方式，并没有错，也和个人能力没有关系，因为这种修改方式是最保险，最快捷的，他不但维持代码原有功能正常运行，还添加了新的功能。
但是，这样的项目，就是典型的破窗效应，因为第一个人产生了破窗，没有及时修复，后面来的人，就会更大胆的破坏，最终项目没法维护。
那如何避免项目形成破窗效应呢？
1、制定代码规范：尽量使用自动化工具实时检测，不要试图通过文档规范，文档一般都不会有人看的，前端集成eslint就最好了，vs code可以安装相应插件实时提醒。另外，可以加入git hook，对不符合规范对代码，拒绝进入代码仓库。
2、code review: 静态代码检测，只能检查语法问题，但是对于代码设计问题，需要code review进行纠正，code review可以利用gitlab 或者 github的 pull request模式，对需要合并到主分支的代码进行review。
3、控制圈复杂度：代码好坏的一个重要标准是，函数的圈复杂度，如果一个函数有大量分支，会让人很难理解，所以控制圈复杂度可以有效提高代码质量，vs code可以利用CodeMetrics这款插件实时检查。
4、控制代码重复率：《编写有效的单元测试》书中提到，重复的代码是造成代码bug提高很重要的因素，我们可以利用SonarQube对代码重复率进行扫描，删除重复代码或者对相近的代码进行封装。
5、自动化单元测试：很多人可能会觉得单元测试成本太高，为什么会产生这样的感觉呢，我觉得主要是大家把开发成本理解为开发功能所需要的时间，但是实际上，项目的成本，包含开发成本，维护成本，bug处理成本，代码二次开发成本。开发成本也许只占项目成本的10%，后面功能越是复杂，维护成本将会出现指数增长，前期不去控制复杂度，会给后期带来巨大的成本开销。
那如果已经是一个破烂不堪的项目，又如何拯救它呢？
1、eslint自动修复：还是上面说的代码规范，我们需要利用eslint进行老代码清理，使用eslint –fix命令，可以实行自动格式化。
2、质量仪表盘：如果你在一个团队工作，必须让大家形成共同目标，并能实时感知项目的状态，否则，你清理代码的速度远比不上创造坏代码的速度。SonarQube是你的好帮手，你可以利用他的仪表盘功能，每天查看项目是否有新增坏代码。
3、重构你的核心模块：如果你要经常修改的模块又是核心模块，建议你对其进行重构，重构时，利用单元测试进行覆盖，保障代码质量，同时，团队成本要进行review，防止把代码修改为你喜好的代码，而非大家能理解的代码。
4、使用率低的模块：对于使用率或者修改率较低的代码，就让他随风去把，时间会带走他的。