如何理解軟件系統中的熱力學第二定律

本篇內容主要講解“如何理解軟件系統中的熱力學第二定律”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何理解軟件系統中的熱力學第二定律”吧!

1.破窗理論

設想下有兩個團隊正在同時進展同樣的項目。團隊A，在項目開發過程中，盡管制定了詳細和周全的計劃，擁有能力最強的工程師，項目的最終結果也不盡人意，隨著項目時間推移，代碼變得很差。

而另外一個團隊B，在開發項目時，盡管也遇到了很大的困難和接二連三的問題，但是卻能保持良好的代碼狀態，圓滿的完成了項目任務。

是什么原因造成了這個差異呢?

在城市中，我們總能發現事物相反面，例如：有整潔漂亮的建筑，而另一些卻是破爛不堪的房子。是什么造成了這么強烈的沖擊感呢?

這兩個現象的原因是一致的，就是“破窗理論”。

以一幢有少許破窗的建筑為例，如果那些窗不被修理好，可能將會有破壞者破壞更多的窗戶。最終破壞者甚至會闖入建筑內，如果發現無人居住，甚至就在里面定居或者縱火。在相當短的一段時間內，建筑就會以驚人的速度被破壞掉，而且業主也不愿意去修理這個破爛的房子了。

對應到軟件開發領域時，這個”破窗戶“，可能是工程師不經意間留下，可能是考慮不周導致，可能是低劣的設計遺留，也可能是錯誤的需求導致。

之前我們團隊內部重構過代碼架構，很多業務都進行了重新設計，但是隨著時間的推移，破窗開始出現，后面就迅速就變得難以維護，臃腫。當然還有其他原因，但是最重要的原因就是對有問題代碼置之不理。

不要留著“破窗戶”，見到一個就就修一個。如果沒有足夠多的時間去修復，最好就加上注釋或者是打個bug標記，表示這部分代碼需要進行修復，防止窗戶破的越來越多。

2.溫水煮青蛙

美國康奈爾大學的科學家做過的一個溫水煮蛙實驗：將一只青蛙放進沸水中，青蛙一碰沸騰的熱水會立即奮力一躍從鍋中跳出逃生;

又嘗試把這只青蛙放進裝有冷水的鍋里，青蛙如常在水中暢游，然后慢慢將鍋里的水加溫，直到水燙得無法忍受時，青蛙再想躍出水面逃離危險的環境卻已四肢無力，最終死在熱水中。

實驗說明的是由于對漸變的適應性和習慣性，失去了警惕和反抗力的道理。

在程序系統中也是適用的，程序員們工作時間久了，就會進入一種安逸的狀態，稱之為“舒適區”。在舒適區中，程序員往往是一種麻痹的狀態，對外界的變化感知麻木。

軟件代碼在時間的長河中，慢慢地、悄無聲息的發生著變化，這個變化最終將會失去控制。

大多數的軟件系統都會從微不足道的小bug開始，慢性死亡。

軟件項目被各種各樣的小bug折騰，只能一天天的延期。

軟件項目中的每一個需求，就像是衣服上破的洞，被打上一個個的補丁，最后已經無法看清軟件架構本身的模樣，就像已經無法看清衣服本身的顏色。

最可怕的是，每一個程序員都承認這是正常、可以接受的狀態，每天樂此不疲的進行bugfix，他們就像溫水里的青蛙，享受著這種狀態。絲毫沒有感受到整個軟件系統正在變成垃圾，變的滿目全非。最后迎接他們的是臃腫的、難以維護的代碼。

水煮蛙和破窗效應是不同的，他們的不同點在于是否有主觀意愿。

破窗問題上，軟件系統變得雜亂無章，是程序員們在看到“破窗”時，并沒有及時阻止這種事情發生，從而認為沒有人會注意到這個問題。

而煮蛙問題上，重點是“慢”，如果放在熱水中或者是快速升溫，青蛙是會奮力的一跳，逃出生天的。所以程序員真的只是沒有察覺，軟件系統就在慢慢的走向死亡。

3.自我為中心

下圖是一副非常有名的畫作，名為『從主教花園望見的索爾茲伯里大教堂』，作者康斯太勃爾，英國的著名油畫家。

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

Fisher主教跟畫家先生說：“親愛的畫家，你幫我畫一幅畫吧。把我和我美麗的妻子以及我這大教堂一起畫到畫里。我要把畫留在教堂，成為鎮堂之寶。”于是康斯太勃爾先生很高興的接下這個項目。

畫家開始了辛苦的工作，經過一段時間終于把這幅畫完成了。

畫家畫這幅畫時可能心情不好，所以在教堂塔尖上方的天空有一片烏云。Fisher主教看到這幅畫后，很不滿意。雖然畫家把主教大人、主教夫人和教堂都畫進去了，但是兩口子只在左下角露了個背影，這也就忍了。“下面那幾頭牛是怎么回事，為什么比我們占的鏡頭還多?”主教問。畫家說：“你沒看懂?我是在恭維您呢，是說您和您夫人好牛!”。Fisher先生沒什么話說了，然后又找到了新的吐槽點：“為什么天空的云都是烏云?”。

他邀請畫家再去他家做客，重新觀察，以便于修改畫作。畫家很不高興了，就單獨把畫展出了。展出之后得到很多好評，于是回信給Fisher主教：“你看，大家都說很好看，不用改了。”，Fisher主教收到信后也怒了，回信就說了一句話：“給我改!!!”。

這就是關于需求的故事，我們再看上圖，看看教主和教主夫人被畫到了哪里?您能找到嗎?

大魚教主想要一幅畫，畫里有他們夫妻二人和教堂，需求表達完后，并沒有再對需求進行更具體的說明。

更深入的思考，為何總是會存在描述不清的情況呢?

讀者們肯定也遇到過類似問題，究其更深層次原因，就是“自我中心”。

人的成長過程就是一個“去中心化的”的過程。大約6歲之后，兒童的自我去中心化的能力得到了發展。開始能夠認識到別人的感受、觀點，但是每個人在社會化過程中，會呈現出不同的去自我中心化的狀態。

可以說是每一個成年人都有自我中心，我們的感受，想法，認識不可能做到完全的客觀。所以我們需要利用結構化思維，(可以參考我的另一篇文章《程序員必備能力——結構化思維》)和系統化思考(可以參考我的一篇文章《程序員必備能力——深度思考》)。

在軟件開發過程中，同樣適用這個結論，我認為至少表現如下幾點：

• 程序員在設計、開發時，如果沒有做到完全的按照產品經理的需求進行，難免對代碼的設計進行反復修改，導致熵增

• 程序員正在開發時，隨意變更、打亂架構框架，導致代碼耦合增大，難以維護

4.業務

代碼熵增的常見的客觀原因是主要是業務壓力大，導致沒有時間或意愿講究代碼質量。因為向業務壓力妥協而生產爛代碼之后，開發效率會隨之下降，導致業務壓力更大，形成一種典型的惡性循環。

到此，相信大家對“如何理解軟件系統中的熱力學第二定律”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！