熱力學第二定律，也叫“熵增定律”。這是德國人克勞修斯提出的理論，最初用於揭示事物總是向無序的方向的發展、以及“孤立系統下熱量從高溫物體流向低溫不可逆”的熱力學定律。
“熵”，就是事物的混亂/無序程度，在孤立系統下，熵是不斷增加的，當熵達到最大值時，系統會出現嚴重混亂，最後走向死亡。
圖片來自網路
它很好地解釋了：為什麼一杯開水放著放著就涼了，為什麼沙漠的沙丘全都驚人的相似，為什麼水只能從高處往低處流，為什麼落地的樹葉不會再變成樹。
儘管軟體開發不屬於物理學範疇，也不適用物理學中的定律，但有一個定律對他的影響實在太大了，就是“熱力學第二定律”，即“熵增定律”。常伴我們左右的軟體系統逃不掉熵增定律，仔細觀察，能夠發現它在漸漸地無序增長，變得越來越雜亂無章。
這篇文章就來聊一聊軟體系統 的熵增定律這件事。下面通過三個故事和業務方面事情，帶著大家從人性和客觀的角度出發，觀察軟體系統下的物理定律。
1破窗理論
設想下有兩個團隊正在同時進展同樣的專案。團隊A，在專案開發過程中，儘管制定了詳細和周全的計劃，擁有能力最強的工程師，專案的最終結果也不盡人意，隨著專案時間推移，程式碼變得很差。
而另外一個團隊B，在開發專案時，儘管也遇到了很大的困難和接二連三的問題，但是卻能保持良好的程式碼狀態，圓滿的完成了專案任務。
是什麼原因造成了這個差異呢？
在城市中，我們總能發現事物相反面，例如：有整潔漂亮的建築，而另一些卻是破爛不堪的房子。是什麼造成了這麼強烈的衝擊感呢？
這兩個現象的原因是一致的，就是“破窗理論”。
圖片來自網路
以一幢有少許破窗的建築為例，如果那些窗不被修理好，可能將會有破壞者破壞更多的窗戶。最終破壞者甚至會闖入建築內，如果發現無人居住，甚至就在裡面定居或者縱火。在相當短的一段時間內，建築就會以驚人的速度被破壞掉，而且業主也不願意去修理這個破爛的房子了。
對應到軟體開發領域時，這個”破窗戶“，可能是工程師不經意間留下，可能是考慮不周導致，可能是低劣的設計遺留，也可能是錯誤的需求導致。
之前我們團隊內部重構過程式碼架構，很多業務都進行了重新設計，但是隨著時間的推移，破窗開始出現，後面就迅速就變得難以維護，臃腫。當然還有其他原因，但是最重要的原因就是對有問題程式碼置之不理。
不要留著“破窗戶”，見到一個就就修一個。如果沒有足夠多的時間去修復，最好就加上註釋或者是打個bug標記，表示這部分程式碼需要進行修復，防止窗戶破的越來越多。
2溫水煮青蛙
美國康奈爾大學的科學家做過的一個溫水煮蛙實驗：將一隻青蛙放進沸水中，青蛙一碰沸騰的熱水會立即奮力一躍從鍋中跳出逃生；
圖片來自網路
又嘗試把這隻青蛙放進裝有冷水的鍋裡，青蛙如常在水中暢遊，然後慢慢將鍋裡的水加溫，直到水燙得無法忍受時，青蛙再想躍出水面逃離危險的環境卻已四肢無力，最終死在熱水中。
實驗說明的是由於對漸變的適應性和習慣性，失去了警惕和反抗力的道理。
在程式系統中也是適用的，程式設計師們工作時間久了，就會進入一種安逸的狀態，稱之為“舒適區”。在舒適區中，程式設計師往往是一種麻痺的狀態，對外界的變化感知麻木。
軟體程式碼在時間的長河中，慢慢地、悄無聲息的發生著變化，這個變化最終將會失去控制。
大多數的軟體系統都會從微不足道的小bug開始，慢性死亡。
軟體專案被各種各樣的小bug折騰，只能一天天的延期。
軟體專案中的每一個需求，就像是衣服上破的洞，被打上一個個的補丁，最後已經無法看清軟體架構本身的模樣，就像已經無法看清衣服本身的顏色。
最可怕的是，每一個程式設計師都承認這是正常、可以接受的狀態，每天樂此不疲的進行bugfix，他們就像溫水裡的青蛙，享受著這種狀態。絲毫沒有感受到整個軟體系統正在變成垃圾，變的滿目全非。最後迎接他們的是臃腫的、難以維護的程式碼。
水煮蛙和破窗效應是不同的，他們的不同點在於是否有主觀意願。
破窗問題上，軟體系統變得雜亂無章，是程式設計師們在看到“破窗”時，並沒有及時阻止這種事情發生，從而認為沒有人會注意到這個問題。
而煮蛙問題上，重點是“慢”，如果放在熱水中或者是快速升溫，青蛙是會奮力的一跳，逃出生天的。所以程式設計師真的只是沒有察覺，軟體系統就在慢慢的走向死亡。
3自我為中心
下圖是一副非常有名的畫作，名為『從主教花園望見的索爾茲伯裡大教堂』，作者康斯太勃爾，英國的著名油畫家。
圖片來自網路
有一天，康斯太勃爾去他的金主大教堂的主教Fisher先生家裡玩。
Fisher主教跟畫家先生說：“親愛的畫家，你幫我畫一幅畫吧。把我和我美麗的妻子以及我這大教堂一起畫到畫裡。我要把畫留在教堂，成為鎮堂之寶。”於是康斯太勃爾先生很高興的接下這個專案。
畫家開始了辛苦的工作，經過一段時間終於把這幅畫完成了。
畫家畫這幅畫時可能心情不好，所以在教堂塔尖上方的天空有一片烏雲。Fisher主教看到這幅畫後，很不滿意。雖然畫家把主教大人、主教夫人和教堂都畫進去了，但是兩口子只在左下角露了個背影，這也就忍了。“下面那幾頭牛是怎麼回事，為什麼比我們佔的鏡頭還多？”主教問。畫家說：“你沒看懂？我是在恭維您呢，是說您和您夫人好牛！”。Fisher先生沒什麼話說了，然後又找到了新的吐槽點：“為什麼天空的雲都是烏雲？”。
他邀請畫家再去他家做客，重新觀察，以便於修改畫作。畫家很不高興了，就單獨把畫展出了。展出之後得到很多好評，於是回信給Fisher主教：“你看，大家都說很好看，不用改了。”，Fisher主教收到信後也怒了，回信就說了一句話：“給我改！！！”。
這就是關於需求的故事，我們再看上圖，看看教主和教主夫人被畫到了哪裡？您能找到嗎？
大魚教主想要一幅畫，畫裡有他們夫妻二人和教堂，需求表達完後，並沒有再對需求進行更具體的說明。
更深入的思考，為何總是會存在描述不清的情況呢？
讀者們肯定也遇到過類似問題，究其更深層次原因，就是“自我中心”。
人的成長過程就是一個“去中心化的”的過程。大約6歲之後，兒童的自我去中心化的能力得到了發展。開始能夠認識到別人的感受、觀點，但是每個人在社會化過程中，會呈現出不同的去自我中心化的狀態。
可以說是每一個成年人都有自我中心，我們的感受，想法，認識不可能做到完全的客觀。所以我們需要利用結構化思維，（可以參考我的另一篇文章《程式設計師必備能力——結構化思維》）和系統化思考（可以參考我的一篇文章《程式設計師必備能力——深度思考》）。
在軟體開發過程中，同樣適用這個結論，我認為至少表現如下幾點：
-
程式設計師在設計、開發時，如果沒有做到完全的按照產品經理的需求進行，難免對程式碼的設計進行反覆修改，導致熵增
-
程式設計師正在開發時，隨意變更、打亂架構框架，導致程式碼耦合增大，難以維護
4業務
程式碼熵增的常見的客觀原因是主要是業務壓力大，導致沒有時間或意願講究程式碼質量。因為向業務壓力妥協而生產爛程式碼之後，開發效率會隨之下降，導致業務壓力更大，形成一種典型的惡性迴圈。
在軟體我們可以通過下圖一覽。
05最後的總結
如果物理學只能留一條定律，我會留熵增定律。這個規律包括我們所有生命和非生命的演化規律，當然軟體系統也無法逃脫。所有的世間萬物都無法逃避。
上面3個故事，是從人性和客觀的角度出發，軟體系統的熵增一定是會發生。我們要做的是減少他發生程度。
熵增定律是針對宇宙的，那如果要針對地球，針對一個國家，針對一個企業，針對某一個人，一個軟體系統呢？則要加上兩個限制條件——封閉系統＋無外力做功。
所以怎樣減少對抗熵增呢？
我們可以針對這兩個條件：封閉系統和無外力做功。只要打破這兩個條件，我們就有可能實現熵減。方法有兩條：外部做功和開發系統。這部分內容我們下一篇文章進行分析！
推薦閱讀（乾貨）程式設計師進階必備能力——晉升之道談一談程式設計師的職業發展路線
送給剛畢業的程式設計師——7點建議程式設計師進階技術專家必備能力——深度思考程式設計師如何選擇一家好公司
覺得不錯，記得關注、轉發和在看！多年經驗分享，實屬不易，感謝支援！
博主是一位物聯網大廠技術總監，從業7年。從軟體開發、高階軟體開發、技術經理再到技術總監，分享職業發展、技術管理、職場晉升、技術成長等個人多年經驗和心得。一起成長！有問題可以加我微信交流：pointersss
如果你有技術成長煩惱，對未來迷茫；關注我，幫你答疑解惑！
