软件的熵

物理学有个熵增定律，它描述的是一个不可逆的过程。既一个封闭系统，迟早会从有序走到无序。我们研发的系统也遵循同样的规律，随着功能的增加，系统会变得越来越复杂。哪怕你有最好的软件工程师也会如此。

很多人把软件熵当做技术债，其实这不完全对。技术债更多是人为造成的。但两者相同之处就是系统会越来越难用。

软件熵虽然不能避免，但我们可以延缓。最关键的是，不要打坏第一个窗户。

心理学有个破窗效应，是1982年，由美国政治学家威尔森和犯罪学家凯琳提出的。它是指，如果有人打坏了一幢建筑的窗户玻璃，却没有人维修，经过的路人，就会像受到了暗示一样，被诱发打破更多的窗户。然后，这个街区其他建筑的窗户，也可能被打破。然后是其他街区。

我们开发的软件也是如此，对于这一点，我算是很有体会。很多时候这里将就一下，那里将就一下。软件就腐烂了。可能只是因为时间不够，你用了最简单的方式来实现，或者没有按研发规范来实现。但有了第一次，就会有第二次，接着其他同事也会如此。

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

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

煮石头的汤和煮青蛙的汤

有三个战场归途中的士兵饥肠辘辘。他们看到前方有一座村庄，顿时重整精神——他们觉得村民们会给口饭吃。可是当他们抵达那里时，却发现四处门窗紧闭。多年战乱下，村民们食物短缺，仅有的存粮都藏了起来。 

士兵们没有气馁，他们烧了一锅水，小心翼翼地在里面放了三块石头。诧异的村民们都跑出来围观。“这叫石头汤。”士兵们解释道。“你们在汤里只放这个？”村民们问道。“对——不过有人说如果加点胡萝卜味道会好一些……”一个村民转身跑回了家，从自己的窖藏中拎来了一筐胡萝卜。几分钟之后，村民们又问道“这就可以了吗？” “可以了，”士兵们说道，“加几个土豆或许更有味道。”另一个村民听到后跑开了。 

在接下来的一个小时内，士兵们列出了更多食材：牛肉、韭菜、盐及各种香料，说能让汤做得更加鲜美。每次都有不同的村民跑回去取来自己的私藏。最后，他们煮了一大锅热气腾腾的汤。士兵们把汤里的石头扔掉，和整个村子的村民一起分享了一顿美餐，这是他们所有人几个月以来吃的第一顿饱餐。

这就是”煮石头的汤“，这个故事我有两个理解。

一、这个故事讲了一个通过团队协作获得成功的案例。每个人拥有不同的优势，整合起来就能做出一个非常优秀的产品。关键是那个石头和拿出石头的人。石头代表着合作的基础，拿出来的人是组织者。

二、一个成功的产品，你需要先让人看到一部分功能，也就是最开始煮的那个石头，他是不是真的有用？不确定，但至少给其他人一个希望，好像加点什么会更好，每一次的迭代又能吸引更多人进来。通过持续迭代，成功的产品就出来了。

还有个故事，就是我们都熟知的，温水煮青蛙。

如果你抓住一只青蛙，把它扔进沸水中，它立刻就会跳出来。但是，如果你把青蛙放在一锅冷水中，然后缓慢地加热，青蛙就不会意识到水温在缓慢上升，直到它们被煮熟。

煮青蛙的汤给我的启示是，不要忽略那种长期的短暂的变化。变化可能是好，也可能是坏。如果是坏的，如何辨别？

挑战

· 在审阅第一版的草稿时，John Lakos提出了这样一个问题：士兵们一步步地欺骗着村民，但他们作为催化剂促成的变化对大家都好。然而，你一步步地欺骗青蛙，却是在伤害它。你在催生变化的时候，能判别是在做石头汤还是青蛙汤吗？这个决定是出于主观还是客观？

如果要我回答的话，所有人的主观合在一起就是客观。项目是变好还是变坏，其实我们自己心里都有谱，变好了那不用说，很少有人会说服自己本来很好的项目说成不好，反倒是很多本来已经变坏的项目，一直在欺骗自己，再加把力就能成功。要想得到真实客观的结论，每个人必须坦诚。把问题抛出来，然后看问题的背后是什么。这个结论是否真的说服了自己，要多问几个，”这是真的吗？“