软件的熵（Entropy of software）

软件的熵

虽然软件开发不受绝大多数物理法则的约束，但我们无法躲避来自熵的增加的重击。熵是一个物理学术语，它定义了一个系统的“无序”总量。不幸的是，热力学法则决定了宇宙中的熵会趋向最大化。当软件中的无序化增加时，程序员会说“软件在腐烂”。有些人可能会用更乐观的术语来称呼它，即“技术债”，潜台词是说他们总有一天会偿还的–恐怕不会还了。

不过不管叫什么名字，债务和腐烂都可能失控地蔓延开。

有很多因素会导致软件腐烂。最重要的一个似乎是项目工作中的心理性状态，或者说文化。即使是一个单人团队，你的项目的心理性状态也是个非常脆弱的东西。即使有最合理的计划和最佳的人员，项目还是可能在生命周期中逐步荒废、腐烂。但也有一些项目在经历了巨大的困难、持续不断的挫折之后，成功地对抗了天然的无序化倾向，走出了困境。

是什么造成了差异？

在城市中心，有些建筑干净漂亮，而另一些则破落不堪。为什么会这样？一些犯罪和城市衰败领域的研究人员发现了一个有趣的触发机制，只需一样东西就能非常迅速地把一幢干净完好的宜居建筑变成一个破败的废弃物。

一扇破窗。

一扇破损的窗户，只要一段时间不去修理，建筑中的居民就会潜移默化地产生一种被遗弃的感觉–当权者不关心这幢建筑的感觉。然后，其他的窗户也开始损坏，居民开始乱丢废物，墙上开始出现涂鸦，建筑开始出现严重的结构性损坏。在一段看上去很短的时间内，建筑的损坏程度就足以打消业主们想修好它的期望，被遗弃的感觉最终变成了现实。为何造成这样的影响？心理学家的研究表明，绝望是会传染的，就像狭窄空间中的流感病毒。无视一个明显损坏的东西，会强化这样一种观念:看来没有什么是能修好的，也没人在乎，一切都命中注定了。所有的负面情绪会在团队成员间蔓延，变成恶性循环。

不要放任破窗

不要搁置“破窗”(糟糕的设计、错误的决定、低劣的代码)不去修理。每发现一个就赶紧修一个。如果没有足够的时间完全修好，那么就把它钉起来。也许你可以注释掉那些糟糕的代码，显示一行“尚未实现”的信息，或用假数据先替代一下。采取行动，预防进一步的损害发生，表明一切尽在你的掌握中。
现在我们了解了一旦窗户开始破裂，运转良好的干净系统会迅速恶化。还有一些其他因素会导致软件腐烂，我们将在别处探讨，但与其他任何因素相比，漠视会加速腐烂的过程。
你或许会觉得，没人有时间来来回回清理项目中所有的碎玻璃。如果你真这么想，劝你还是趁早多想想怎么料理这个项目的后事，或是直接离开是非之地。不要让熵赢得胜利。

先勿伤害

译注：原文为First,Do No Harm，来源于著名的希波克拉底誓词

多年以前，Andy 认识一个土豪。他的房子富丽堂皇，屋子里摆满了无价的古董，到处陈列着精美的艺术品。有一天，一张挂毯因为离客厅壁炉太近而着火了。消防员奋勇冲进去救民于水火，当然主要是火。但是在把巨大的水管拖进屋子前，他们停了下来–尽管里面火势紧急–毅然选择先在前门和火源之间铺上垫子，因为觉得水管太脏。他们不想弄坏地毯。

现在听起来这很偏激。消防部门的首要任务当然是灭火，何必管过程中的那些附带损害呢？但是他们在清醒地评估了形势后，出于对自己控制这场火势能力的绝对自信，还是尽力兼顾了不对财物造成不必要的毁害。这也是软件开发中应该遵循的方法:不要只是因为一些东西非常危急，就去造成附带损害。破窗一扇都嫌太多。

一扇破窗---段设计糟糕的代码，一个让团队在整个项目周期内都必须要遵守的糟糕管理决定--就是一切衰退的开始。如果你发现自己正处在有几扇破窗的项目中，就非常容易陷入这样的想法-“反正代码所有其他部分都是一坨屎，我只是随大流而己。”项目运作在这个时间点前是不是一直良好并不重要。在最初启发“破窗理论”的实验中，一辆废弃的汽车完好无损地停放了一个星期。但是一旦有一块玻璃被打破，这辆车在几个小时内就会被扒光并翻了个底朝天。

出于同样原因，如果身处一个健康团队，你们项目的代码如此完美–编写清晰、设计优良、简洁优雅–你就会倾向于格外地小心，不把它弄糟。就像那些消防员一样，即使屋内火势熊熊(截止时限、发行日期、销售演示，等等)，你也不想成为第一个弄乱它、造成附带损害的人。

一定要告诉自己，"不要打破窗户"

参考：《程序员修炼之道》