热力学第二定律，又称“熵增定律”。这是德国人克劳修斯提出的理论，最初是用来揭示事物向无序方向发展的，热力学定律“孤立系统中高温物体的热量向低温物体的流动”是不可逆转的”。“熵”是指事物混乱/无序的程度。在一个孤立的系统中，熵是不断增加的。当熵达到最大值时，系统将经历严重的混乱并最终死亡。解释的很好：为什么一杯开水放着会变凉，为什么沙漠里的沙丘都惊人的相似，为什么水只能从高处流向低处，为什么落叶不会变成树再次。软件开发虽然不属于物理学范畴，也不适用物理定律，但有一个定律对他影响很大，这就是“热力学第二定律”，即“热力学定律”。熵增”。时刻陪伴在我们身边的软件系统，都逃不过熵增定律。如果你仔细观察，你会发现它逐渐变得无序，并且越来越混乱。本文将讨论软件系统中的熵增定律。下面三个故事和业务事项，将带领大家从人性、客观的角度去观察软件系统下的物理规律。1.破窗理论假设两个团队同时在同一个项目上工作。A队，在项目开发过程中，尽管有详细全面的计划，拥有最有能力的工程师，但项目的最终结果并不令人满意。随着项目时间的推移，代码变得非常糟糕。而另一个团队B，虽然在项目开发过程中也遇到了很大的困难和接二连三的问题，但都能够保持良好的代码状态，顺利完成了项目任务。是什么导致了这种差异？在城市里，我们总能找到对立面，比如：有干净漂亮的建筑，也有破旧的房子。是什么造成了如此强烈的冲击感？这两种现象产生的原因是一样的，就是“破窗论”。以一栋有几扇窗户破损的建筑物为例，如果这些窗户不修好，可能会有更多的窗户被破坏者损坏。最终破坏者甚至会闯入建筑物，如果发现无人居住，甚至会在其中定居或放火。在较短的时间内，建筑物将以惊人的速度被摧毁，而业主也舍不得对破旧的房屋进行修缮。对应到软件开发领域，这个“破窗”可能是工程师无意中留下的，可能是考虑不周造成的，可能是设计不周遗留下来的，也可能是错误的需求造成的。在我们团队内部重构代码结构之前，很多业务都是重新设计的，但是随着时间的推移，开始出现破窗，很快就变得难以维护和臃肿。当然还有其他原因，但最重要的原因是不要管有问题的代码。不要保留“破窗”，看到一扇就修一扇。如果没有足够的时间修复它，最好添加注释或标记错误以表明这部分代码需要修复，以防止越来越多的破窗。2、温水煮青蛙美国康奈尔大学的科学家做过温水煮青蛙的实验：将一只青蛙放入沸水中，当青蛙接触到沸腾的热水时，它会立即跳出锅逃脱；再试一次把这只青蛙放入装有冷水的锅里，青蛙照常在水里游来游去，然后把锅里的水慢慢加热，直到水热得受不了，青蛙想跳出水面躲避危险的环境，但它已经消失了。他四肢无力，最终死在热水中。实验表明，由于对渐变的适应和习惯，人们失去了警惕和抵抗力。也适用于程序系统。工作时间长了，程序员会进入一个舒服的状态，这个状态叫做“舒适区”。在舒适区，程序员往往处于麻痹状态，对外界的变化麻木。软件代码在时间的长河中缓慢而无声地变化着，而这种变化终将失控。大多数软件系统都是从微不足道的错误开始的，然后慢慢消亡。软件项目被各种小bug折腾，只能一天天拖延。软件项目中的每一个需求就像是衣服上的一个洞，需要一个一个补上。最终无法看到软件架构本身的外观，就像衣服本身的颜色一样。最可怕的是，每个程序员都承认这是一种正常的、可以接受的状态，每天都乐呵呵地进行bugfix。他们就像温水中的青蛙，享受着这种状态。完全没有感觉到整个软件系统变得垃圾，变得面目全非了。他们最终得到了臃肿的、无法维护的代码。水煮青蛙不同于破窗效应。区别在于有没有主观意志。在破窗问题上，软件系统已经变得杂乱无章。当程序员看到“破窗”时，并没有及时阻止这种事情的发生，所以他们认为没有人会注意到这个问题。至于煮青蛙的问题，关键是“慢”。如果将其放入热水中或迅速加热，青蛙就会使劲一跃而逃。所以程序员真的就是意识不到，软件系统也在慢慢消亡。3.以自我为中心下图是一幅非常有名的画作，叫做《从主教花园看索尔兹伯里大教堂》，是英国著名油画家康斯特布尔的作品。有一天，Constable去他的金色大教堂的主教Fisher先生家里玩。费舍尔主教对画家先生说：“亲爱的画家，请帮我画一幅画。把我和我美丽的妻子以及我的大教堂一起画在画里。我想把画留在教堂里，成为市政厅。”宝藏。”于是Constable先生愉快地接手了这个项目。画家开始努力工作，经过一段时间终于完成了这幅画。可能是画家画这幅画的时候心情不好，所以阴云密布。教堂尖顶上方的天空，费舍尔主教看到这幅画后，非常不满意，虽然画师画了主教、主教夫人和教堂，但左下角只露出这对夫妇的背影，这还可以接受。主教问：“下面的牛怎么了，为什么比我们占得多？”画家说：“你不明白吗？我在恭维你。我是说你和你老婆真棒！”。费舍尔先生无话可说，又找到了新的抱怨点：“为什么天上的云是乌云？”。他再次邀请画家到他家做客重新观察和修改画作，画家很不高兴，就单独展出了这幅画，展览结束后，得到了很多好评，于是我回信给费舍尔主教：“看，大家都说很好看，所以没有必要改变它。“!!!”。这是关于需求的故事。大家看看上图，看看领导夫妇画在哪里？你能找到吗？大鱼的首领想要一幅画，里面有他们的夫妻和教堂，表示需要，之后就没有更具体的描述要求了。再深思一下，为什么总有不明朗的情况？读者一定遇到过类似的问题，更深层次的原因是“以自我为中心”。人的成长过程是一个“去中心化”的过程。大约6岁以后，孩子的自我分散能力开始发展。开始能够认同他人的感受和意见，但每个人在社会化过程中会表现出不同的去中心化状态。可以说，每个成年人都有自我中心，我们的感受、思想、认知不可能是完全客观的。所以我们需要使用结构化思维，（可以参考我的另一篇文章《程序员必备能力——结构化思维》）和系统化思维（可以参考我的一篇文章《程序员必备能力——深度思考》）。在软件开发过程中，这个结论同样适用。我认为至少有以下几点表现：如果程序员在设计开发时没有完全按照产品经理的需求进行设计开发，就不可避免地要反复修改代码设计，导致熵增。架构框架随意，导致代码耦合增加，维护困难。4.业务代码熵增的常见客观原因主要是业务压力大，导致没有时间和意愿去关注代码质量。向业务压力妥协，产生坏代码后，开发效率会下降，导致业务压力变大，形成典型的恶性循环。在软件中，我们可以看看下图。05.结语如果物理学只能守一个定律，我就守熵增定律。这个规律包含了我们所有生命和非生命的进化规律，当然软件系统也逃不掉。世间万物都逃不过。以上三个故事是从人性和客观性的角度出发的，软件系统的熵增是一定会发生的。我们要做的就是减少他出现的程度。熵增定律是针对宇宙的，那么针对地球、国家、企业、某个人、软件系统呢？必须加上两个限制——封闭系统+无外力做功。那么如何降低熵增的阻力呢？我们可以针对这两个条件：封闭的系统和没有外力做功。只要打破这两个条件，我们就有可能实现熵减。有两种方法：外部工作和开发系统。我们将在下一篇文章中分析这部分内容！本文转载自微信?「指点」，可通过以下二维码关注。转载本文请联系指点公众号。
