聊一聊 软件系统中的“热力学第二定律”

热力学第二定律,也叫“熵增定律”。这是德国人克劳修斯提出的理论,最初用于揭示事物总是向无序的方向的发展、以及“孤立系统下热量从高温物体流向低温不可逆”的热力学定律。

 

“熵”,就是事物的混乱/无序程度,在孤立系统下,熵是不断增加的,当熵达到最大值时,系统会出现严重混乱,最后走向死亡。

 

 

图片来自网络

它很好地解释了:为什么一杯开水放着放着就凉了,为什么沙漠的沙丘全都惊人的相似,为什么水只能从高处往低处流,为什么落地的树叶不会再变成树。

 

尽管软件开发不属于物理学范畴,也不适用物理学中的定律,但有一个定律对他的影响实在太大了,就是“热力学第二定律”,即“熵增定律”。常伴我们左右的软件系统逃不掉熵增定律,仔细观察,能够发现它在渐渐地无序增长,变得越来越杂乱无章。

 

这篇文章就来聊一聊软件系统 的熵增定律这件事。下面通过三个故事和业务方面事情,带着大家从人性和客观的角度出发,观察软件系统下的物理定律。


 

1破窗理论

 

设想下有两个团队正在同时进展同样的项目。团队A,在项目开发过程中,尽管制定了详细和周全的计划,拥有能力最强的工程师,项目的最终结果也不尽人意,随着项目时间推移,代码变得很差。

 

而另外一个团队B,在开发项目时,尽管也遇到了很大的困难和接二连三的问题,但是却能保持良好的代码状态,圆满的完成了项目任务。

 

是什么原因造成了这个差异呢?

 

在城市中,我们总能发现事物相反面,例如:有整洁漂亮的建筑,而另一些却是破烂不堪的房子。是什么造成了这么强烈的冲击感呢?

 

这两个现象的原因是一致的,就是“破窗理论”。

 

 

图片来自网络

以一幢有少许破窗的建筑为例,如果那些窗不被修理好,可能将会有破坏者破坏更多的窗户。最终破坏者甚至会闯入建筑内,如果发现无人居住,甚至就在里面定居或者纵火。在相当短的一段时间内,建筑就会以惊人的速度被破坏掉,而且业主也不愿意去修理这个破烂的房子了。

 

对应到软件开发领域时,这个”破窗户“,可能是工程师不经意间留下,可能是考虑不周导致,可能是低劣的设计遗留,也可能是错误的需求导致。

 

之前我们团队内部重构过代码架构,很多业务都进行了重新设计,但是随着时间的推移,破窗开始出现,后面就迅速就变得难以维护,臃肿。当然还有其他原因,但是最重要的原因就是对有问题代码置之不理。

 

不要留着“破窗户”,见到一个就就修一个。如果没有足够多的时间去修复,最好就加上注释或者是打个bug标记,表示这部分代码需要进行修复,防止窗户破的越来越多。


 

2温水煮青蛙

 

美国康奈尔大学的科学家做过的一个温水煮蛙实验:将一只青蛙放进沸水中,青蛙一碰沸腾的热水会立即奋力一跃从锅中跳出逃生;

 

 

图片来自网络

又尝试把这只青蛙放进装有冷水的锅里,青蛙如常在水中畅游,然后慢慢将锅里的水加温,直到水烫得无法忍受时,青蛙再想跃出水面逃离危险的环境却已四肢无力,最终死在热水中。

实验说明的是由于对渐变的适应性和习惯性,失去了警惕和反抗力的道理。

 

在程序系统中也是适用的,程序员们工作时间久了,就会进入一种安逸的状态,称之为“舒适区”。在舒适区中,程序员往往是一种麻痹的状态,对外界的变化感知麻木。

软件代码在时间的长河中,慢慢地、悄无声息的发生着变化,这个变化最终将会失去控制。 

大多数的软件系统都会从微不足道的小bug开始,慢性死亡

软件项目被各种各样的小bug折腾,只能一天天的延期。

软件项目中的每一个需求,就像是衣服上破的洞,被打上一个个的补丁,最后已经无法看清软件架构本身的模样,就像已经无法看清衣服本身的颜色

 

最可怕的是,每一个程序员都承认这是正常、可以接受的状态,每天乐此不疲的进行bugfix,他们就像温水里的青蛙,享受着这种状态。丝毫没有感受到整个软件系统正在变成垃圾,变的满目全非。最后迎接他们的是臃肿的、难以维护的代码。

 

水煮蛙和破窗效应是不同的,他们的不同点在于是否有主观意愿。

 

破窗问题上,软件系统变得杂乱无章,是程序员们在看到“破窗”时,并没有及时阻止这种事情发生,从而认为没有人会注意到这个问题。

而煮蛙问题上,重点是“慢”,如果放在热水中或者是快速升温,青蛙是会奋力的一跳,逃出生天的。所以程序员真的只是没有察觉,软件系统就在慢慢的走向死亡。


 

3自我为中心

 

下图是一副非常有名的画作,名为『从主教花园望见的索尔兹伯里大教堂』,作者康斯太勃尔,英国的著名油画家。

 

 

图片来自网络

有一天,康斯太勃尔去他的金主大教堂的主教Fisher先生家里玩。

Fisher主教跟画家先生说:“亲爱的画家,你帮我画一幅画吧。把我和我美丽的妻子以及我这大教堂一起画到画里。我要把画留在教堂,成为镇堂之宝。”于是康斯太勃尔先生很高兴的接下这个项目。

画家开始了辛苦的工作,经过一段时间终于把这幅画完成了。

画家画这幅画时可能心情不好,所以在教堂塔尖上方的天空有一片乌云。Fisher主教看到这幅画后,很不满意。虽然画家把主教大人、主教夫人和教堂都画进去了,但是两口子只在左下角露了个背影,这也就忍了。“下面那几头牛是怎么回事,为什么比我们占的镜头还多?”主教问。画家说:“你没看懂?我是在恭维您呢,是说您和您夫人好牛!”。Fisher先生没什么话说了,然后又找到了新的吐槽点:“为什么天空的云都是乌云?”。

他邀请画家再去他家做客,重新观察,以便于修改画作。画家很不高兴了,就单独把画展出了。展出之后得到很多好评,于是回信给Fisher主教:“你看,大家都说很好看,不用改了。”,Fisher主教收到信后也怒了,回信就说了一句话:“给我改!!!”。

这就是关于需求的故事,我们再看上图,看看教主和教主夫人被画到了哪里?您能找到吗?

大鱼教主想要一幅画,画里有他们夫妻二人和教堂,需求表达完后,并没有再对需求进行更具体的说明。

更深入的思考,为何总是会存在描述不清的情况呢?

读者们肯定也遇到过类似问题,究其更深层次原因,就是“自我中心”。

人的成长过程就是一个“去中心化的”的过程。大约6岁之后,儿童的自我去中心化的能力得到了发展。开始能够认识到别人的感受、观点,但是每个人在社会化过程中,会呈现出不同的去自我中心化的状态。

可以说是每一个成年人都有自我中心,我们的感受,想法,认识不可能做到完全的客观。所以我们需要利用结构化思维,(可以参考我的另一篇文章《程序员必备能力——结构化思维》)和系统化思考(可以参考我的一篇文章《程序员必备能力——深度思考》)。

在软件开发过程中,同样适用这个结论,我认为至少表现如下几点:

  • 程序员在设计、开发时,如果没有做到完全的按照产品经理的需求进行,难免对代码的设计进行反复修改,导致熵增

  • 程序员正在开发时,随意变更、打乱架构框架,导致代码耦合增大,难以维护


     

 

 

4业务

 

代码熵增的常见的客观原因是主要是业务压力大,导致没有时间或意愿讲究代码质量。因为向业务压力妥协而生产烂代码之后,开发效率会随之下降,导致业务压力更大,形成一种典型的恶性循环。

 

 

 

 

在软件我们可以通过下图一览。

 

 

 

 

 

 

05最后的总结

 

如果物理学只能留一条定律,我会留熵增定律。这个规律包括我们所有生命和非生命的演化规律,当然软件系统也无法逃脱。所有的世间万物都无法逃避。

 

上面3个故事,是从人性和客观的角度出发,软件系统的熵增一定是会发生。我们要做的是减少他发生程度。

熵增定律是针对宇宙的,那如果要针对地球,针对一个国家,针对一个企业,针对某一个人,一个软件系统呢?则要加上两个限制条件——封闭系统+无外力做功。

所以怎样减少对抗熵增呢?

我们可以针对这两个条件:封闭系统和无外力做功。只要打破这两个条件,我们就有可能实现熵减。方法有两条:外部做功和开发系统。这部分内容我们下一篇文章进行分析!

 

 




推荐阅读(干货)程序员进阶必备能力——晋升之道谈一谈程序员的职业发展路线
送给刚毕业的程序员——7点建议程序员进阶技术专家必备能力——深度思考程序员如何选择一家好公司

 



觉得不错,记得关注、转发和在看!多年经验分享,实属不易,感谢支持!


 

博主是一位物联网大厂技术总监,从业7年。从软件开发、高级软件开发、技术经理再到技术总监,分享职业发展、技术管理、职场晋升、技术成长等个人多年经验和心得。一起成长!有问题可以加我微信交流:pointersss
如果你有技术成长烦恼,对未来迷茫;关注我,帮你答疑解惑!

 

posted @ 2020-10-28 18:14  袁吴范pointers  阅读(914)  评论(1编辑  收藏  举报