热力学第二定律，也叫“熵增定律”。这是德国人克劳修斯提出的理论，最初用于揭示事物总是向无序的方向的发展、以及“孤立系统下热量从高温物体流向低温不可逆”的热力学定律。
“熵”，就是事物的混乱/无序程度，在孤立系统下，熵是不断增加的，当熵达到最大值时，系统会出现严重混乱，最后走向死亡。
它很好地解释了：为什么一杯开水放着放着就凉了，为什么沙漠的沙丘全都惊人的相似，为什么水只能从高处往低处流，为什么落地的树叶不会再变成树。
尽管软件开发不属于物理学范畴，也不适用物理学中的定律，但有一个定律对他的影响实在太大了，就是“热力学第二定律”，即“熵增定律”。常伴我们左右的软件系统逃不掉熵增定律，仔细观察，能够发现它在渐渐地无序增长，变得越来越杂乱无章。
这篇文章就来聊一聊软件系统 的熵增定律这件事。下面通过三个故事和业务方面事情，带着大家从人性和客观的角度出发，观察软件系统下的物理定律。
1.破窗理论
设想下有两个团队正在同时进展同样的项目。团队A，在项目开发过程中，尽管制定了详细和周全的计划，拥有能力最强的工程师，项目的最终结果也不尽人意，随着项目时间推移，代码变得很差。
而另外一个团队B，在开发项目时，尽管也遇到了很大的困难和接二连三的问题，但是却能保持良好的代码状态，圆满的完成了项目任务。
是什么原因造成了这个差异呢?
在城市中，我们总能发现事物相反面，例如：有整洁漂亮的建筑，而另一些却是破烂不堪的房子。是什么造成了这么强烈的冲击感呢?
这两个现象的原因是一致的，就是“破窗理论”。
以一幢有少许破窗的建筑为例，如果那些窗不被修理好，可能将会有破坏者破坏更多的窗户。最终破坏者甚至会闯入建筑内，如果发现无人居住，甚至就在里面定居或者纵火。在相当短的一段时间内，建筑就会以惊人的速度被破坏掉，而且业主也不愿意去修理这个破烂的房子了。
对应到软件开发领域时，这个”破窗户“，可能是工程师不经意间留下，可能是考虑不周导致，可能是低劣的设计遗留，也可能是错误的需求导致。
之前我们团队内部重构过代码架构，很多业务都进行了重新设计，但是随着时间的推移，破窗开始出现，后面就迅速就变得难以维护，臃肿。当然还有其他原因，但是最重要的原因就是对有问题代码置之不理。
不要留着“破窗户”，见到一个就就修一个。如果没有足够多的时间去修复，最好就加上注释或者是打个bug标记，表示这部分代码需要进行修复，防止窗户破的越来越多。
2.温水煮青蛙
美国康奈尔大学的科学家做过的一个温水煮蛙实验：将一只青蛙放进沸水中，青蛙一碰沸腾的热水会立即奋力一跃从锅中跳出逃生;
又尝试把这只青蛙放进装有冷水的锅里，青蛙如常在水中畅游，然后慢慢将锅里的水加温，直到水烫得无法忍受时，青蛙再想跃出水面逃离危险的环境却已四肢无力，最终死在热水中。
实验说明的是由于对渐变的适应性和习惯性，失去了警惕和反抗力的道理。
在程序系统中也是适用的，程序员们工作时间久了，就会进入一种安逸的状态，称之为“舒适区”。在舒适区中，程序员往往是一种麻痹的状态，对外界的变化感知麻木。
软件代码在时间的长河中，慢慢地、悄无声息的发生着变化，这个变化最终将会失去控制。
大多数的软件系统都会从微不足道的小bug开始，慢性死亡。
软件项目被各种各样的小bug折腾，只能一天天的延期。
软件项目中的每一个需求，就像是衣服上破的洞，被打上一个个的补丁，最后已经无法看清软件架构本身的模样，就像已经无法看清衣服本身的颜色。
最可怕的是，每一个程序员都承认这是正常、可以接受的状态，每天乐此不疲的进行bugfix，他们就像温水里的青蛙，享受着这种状态。丝毫没有感受到整个软件系统正在变成垃圾，变的满目全非。最后迎接他们的是臃肿的、难以维护的代码。
水煮蛙和破窗效应是不同的，他们的不同点在于是否有主观意愿。
破窗问题上，软件系统变得杂乱无章，是程序员们在看到“破窗”时，并没有及时阻止这种事情发生，从而认为没有人会注意到这个问题。
而煮蛙问题上，重点是“慢”，如果放在热水中或者是快速升温，青蛙是会奋力的一跳，逃出生天的。所以程序员真的只是没有察觉，软件系统就在慢慢的走向死亡。
3.自我为中心
下图是一副非常有名的画作，名为『从主教花园望见的索尔兹伯里大教堂』，作者康斯太勃尔，英国的著名油画家。
有一天，康斯太勃尔去他的金主大教堂的主教Fisher先生家里玩。
Fisher主教跟画家先生说：“亲爱的画家，你帮我画一幅画吧。把我和我美丽的妻子以及我这大教堂一起画到画里。我要把画留在教堂，成为镇堂之宝。”于是康斯太勃尔先生很高兴的接下这个项目。
画家开始了辛苦的工作，经过一段时间终于把这幅画完成了。
画家画这幅画时可能心情不好，所以在教堂塔尖上方的天空有一片乌云。Fisher主教看到这幅画后，很不满意。虽然画家把主教大人、主教夫人和教堂都画进去了，但是两口子只在左下角露了个背影，这也就忍了。“下面那几头牛是怎么回事，为什么比我们占的镜头还多?”主教问。画家说：“你没看懂?我是在恭维您呢，是说您和您夫人好牛!”。Fisher先生没什么话说了，然后又找到了新的吐槽点：“为什么天空的云都是乌云?”。
他邀请画家再去他家做客，重新观察，以便于修改画作。画家很不高兴了，就单独把画展出了。展出之后得到很多好评，于是回信给Fisher主教：“你看，大家都说很好看，不用改了。”，Fisher主教收到信后也怒了，回信就说了一句话：“给我改!!!”。
这就是关于需求的故事，我们再看上图，看看教主和教主夫人被画到了哪里?您能找到吗?
大鱼教主想要一幅画，画里有他们夫妻二人和教堂，需求表达完后，并没有再对需求进行更具体的说明。
更深入的思考，为何总是会存在描述不清的情况呢?
读者们肯定也遇到过类似问题，究其更深层次原因，就是“自我中心”。
人的成长过程就是一个“去中心化的”的过程。大约6岁之后，儿童的自我去中心化的能力得到了发展。开始能够认识到别人的感受、观点，但是每个人在社会化过程中，会呈现出不同的去自我中心化的状态。
可以说是每一个成年人都有自我中心，我们的感受，想法，认识不可能做到完全的客观。所以我们需要利用结构化思维，(可以参考我的另一篇文章《程序员必备能力——结构化思维》)和系统化思考(可以参考我的一篇文章《程序员必备能力——深度思考》)。
在软件开发过程中，同样适用这个结论，我认为至少表现如下几点：
- 程序员在设计、开发时，如果没有做到完全的按照产品经理的需求进行，难免对代码的设计进行反复修改，导致熵增
- 程序员正在开发时，随意变更、打乱架构框架，导致代码耦合增大，难以维护
4.业务
代码熵增的常见的客观原因是主要是业务压力大，导致没有时间或意愿讲究代码质量。因为向业务压力妥协而生产烂代码之后，开发效率会随之下降，导致业务压力更大，形成一种典型的恶性循环。
在软件我们可以通过下图一览。
05.最后的总结
如果物理学只能留一条定律，我会留熵增定律。这个规律包括我们所有生命和非生命的演化规律，当然软件系统也无法逃脱。所有的世间万物都无法逃避。
上面3个故事，是从人性和客观的角度出发，软件系统的熵增一定是会发生。我们要做的是减少他发生程度。
熵增定律是针对宇宙的，那如果要针对地球，针对一个国家，针对一个企业，针对某一个人，一个软件系统呢?则要加上两个限制条件——封闭系统+无外力做功。
所以怎样减少对抗熵增呢?
我们可以针对这两个条件：封闭系统和无外力做功。只要打破这两个条件，我们就有可能实现熵减。方法有两条：外部做功和开发系统。这部分内容我们下一篇文章进行分析!
本文转载自微信公众号「pointers」，可以通过以下二维码关注。转载本文请联系pointers公众号。
