不要留破窗

破窗

最近对一个别人写的页面做一些改动，发现越改越难改。做的改动越大，越发现当初写这个页面的人，对页面的代码结构设计上存在很多想当然，很随便的地方，以至于我想要在这个页面上做拓展的愿望很难实现。好不容易加进去了，也只是让这个页面的逻辑更加复杂难懂，看着自己加的代码，自己都觉得难受，但又无奈没时间对整个页面重构一把。

类似的事情其实在做之前的项目P时一直存在。刚接触项目P的时候就觉得代码晦涩难懂，逻辑混乱，充斥着许多无用的重复的代码。实在看不懂了，去问还在做这个项目的人，得到的回复基本都是“这个东西就是这样的，没办法”“哦忘了跟你说，这里还有个坑。”之类的答复。显然，所有的开发维护人员都对这个项目的代码质量无奈了。在这个基础上，当有人需要加新代码进去的时候，对自己的代码质量也会不做要求：反正都这么乱了，再乱一点又会怎样？

这不就是破窗效应的最好体现吗？

破窗效应（英语：Broken windows theory）是犯罪学的一个理论，该理论由詹姆士·威尔逊（James Q. Wilson）及乔治·凯林（George L. Kelling）提出，并刊于《The Atlantic Monthly》1982年3月版的一篇题为《Broken Windows》的文章。

此理论认为环境中的不良现象如果被放任存在，会诱使人们仿效，甚至变本加厉。一幢有少许破窗的建筑为例，如果那些窗不被修理好，可能将会有破坏者破坏更多的窗户。最终他们甚至会闯入建筑内，如果发现无人居住，也许就在那里定居或者纵火。一面墙，如果出现一些涂鸦没有被清洗掉，很快的，墙上就布满了乱七八糟、不堪入目的东西；一条人行道有些许纸屑，不久后就会有更多垃圾，最终人们会视若理所当然地将垃圾顺手丢弃在地上。这个现象，就是犯罪心理学中的破窗效应。

这样的情况也不是不能避免的。作为一个团队，我们可以制定合理的规定来减少想当然的代码，比如进行代码review。同时，强制代码的结构，模版，甚至提供严格的api,都可以一定程度阻止这种情况的发生（说到这里我开始理解了团队的老司机为什么不断的提出新的标准让我们遵守）；作为个人，在写下每一次代码的时候，都需要确定自己没有留下破窗，一切都是干净整齐的。

否则，过段时间你再回来看自己创建的代码，绝对已经成为又一个公共垃圾场了。

一份干净的代码更容易保持干净，一块整洁的地方更容易保持整洁。工作生活都应当如此。