大家或许都听说过这么个说法：如果有人打坏了一幢建筑物的窗户玻璃，而这扇窗户又得不到及时的维修，别人就可能受到某些示范性的纵容去打烂更多的窗户。

这便是所谓的“破窗效应”，它有真实的理论由来：美国斯坦福大学心理学家菲利普·津巴多于1969年进行了一项实验，他找来两辆一模一样的汽车，把其中的一辆停在加州帕洛阿尔托的中产阶级社区，而另一辆停在相对杂乱的纽约布朗克斯区。停在布朗克斯的那辆，他把车牌摘掉，把顶棚打开，结果当天就被偷走了。而放在帕洛阿尔托的那一辆，一个星期也无人理睬。后来，用锤子把那辆车的玻璃敲了个大洞，结果呢，仅仅过了几个小时，它就不见了。

“破窗户理论”当时启发了纽约和其他大城市的警察部门，他们对一些轻微的案件严加处理，以防止大案的发生，这也起到了作用。然而，破窗效应同样影响着软件和项目的发展。

有许多因素可以促生软件腐烂，其中最重要的一个似乎是开发项目时的心理（或文化），即使你的团队只有一个人，你开发项目时的心理也可能是非常微妙的事情，尽管制定了最好的计划，拥有最好的开发者，项目在其生命周期中仍会遭遇毁灭和衰败。而另外有一些项目，尽管遇到巨大的困难和接连而来的挫折，却成功地击败自然无序的倾向，取得了相当好的结果。

造成这样巨大的差异，往往可能是因为对待“破窗户”（低劣的设计、错误的决策、或者是糟糕的代码）的态度。想一想你的项目是何时被打破第一扇窗户的？

1、新员工的代码未经复查或审核便合并到了你的项目中。

2、规划好的项目进度，因为发布日期的提前，不得不新增人手，或者仓促实现，不经意间就会丢弃（或者不考虑引进）稍显繁琐却合理的设计规则，导致项目中充斥着所谓“临时实现”和“临时代码”（可能当时心里告诫自己会很快改掉，但随着项目的发展，心理上的变化，你会发现那段糟糕的代码一直呆到了软件的发布）。

3、需求的改变，暴露了现有设计的缺陷，由于你的偷懒、将就，或者项目经理在背后的催促，时间来不及的自我安慰，最终打破了这个“窗户”。

4、团队成员之间没有充分的沟通，没有合理的目标或约定，导致项目中充斥了重复或相似功能的代码。

……

破窗户不可怕，可怕的是你容忍它，不去及时修复它，更可怕的是这正是带来更多破窗户的开始。

我屋子角的沙发上干净、整洁时，周末我便会有兴致捧本书过去沉浸一会。如果上面堆了些书包和衣服，下次我就会不以为然地丢下另外一些东西，当看到一堆（而不是几个）凌乱的东西时，我想要整理的动力就会降低，除非是有人要来做客或者再也忍受不了来个大扫除。

开发软件具有相同的情景。简洁漂亮的代码使人心情愉悦，带来创作的欲望和美的享受。臃肿和杂乱的代码，会使你降低自己的标准，甚至心里已经开始推卸责任了：“反正已经这么乱了，我这样还好吧”。但是项目工程不像是房间来个大扫除那么简单的，当你不得不来个彻底“大扫除”时，你的痛苦便来了，首先你要熟悉并掌控各部分功能，不然很容易引入潜在的bug；其次你得循循渐进，一步步来重构，一步步来测试，这可能需要花费平时修补的数倍时间，这也正是竞争对手追赶或拉开距离的好时机；如果“坏窗户”随着上一个版本已经发布出去，那么你还可能要面对版本兼容这个恶魔。

作为对照，《The Pragmatic Programmer》中有这么个灭火的故事。一个富得让人讨厌的富翁，拥有一所舒适、漂亮的房子，里面满是无价的古董、艺术品等贵重的物品。有一天，一副挂毯挂得离他的卧室壁炉太近了一点，着火了。消防人员冲进来救火和他的房子，但他们拖着粗大、肮脏的消防水管冲到房间门口却停住了——他们要在前门和着火处之间铺上垫子。

这的确是一个极端的事例，但我们必须以这种方式对待软件。一扇破窗户（一段设计低劣的代码，团队必须在整个项目开发过程中忍受的一项糟糕的管理决策），就足以使项目开始衰败。同样的道理，如果你发现所在的团队和项目的代码合理、优雅，你就很可能会格外注意不去弄脏他，就和那些消防员一样，即使有火在咆哮（最后的期限、发布日期、会展演示等），你也不会想成为第一个弄脏东西的人。

其实，拖延和懒惰一样也是我们思想里的破窗户。对顺手整理沙发上的物品拖延，导致某段时间不能享受沙发舒适带来的好兴致；对手头的坏代码拖延，导致某段时间要承受更多的压力回来修复它；对内心深处的声音或焦虑拖延，可能导致穷尽一生去追寻或弥补也未必。

本篇为原创文章，转载请标明出处。