熱力學第二定律和代碼維護
1.物理學是一個非常有意思的學科。無論是經典物理學還是現代物理學，時間在絕大多數的定律里面是雙向的，不存在著一個唯一的方向。但是現實經驗告訴我們時間只有一個方向，比如說我們可以看到瓶子破碎了，但是卻不能看到破碎的瓶子復原。
熱力學第二定律是一個特例，熱力學第二定律告訴我們一個孤立的系統的熵在不斷增加。通俗一點講，一個孤立系統會越來越混亂。
那么怎么樣才能夠讓系統穩定呢?需要新的低熵的能量。這讓我聯想到了代碼開發。自從香農的信息論出來以后，信息熵的概念也大行其道了。所以代碼開發這種純粹的信息系統，其實也符合熱力學第二定律。
2.我在微軟工作的時候曾經見過一個微軟的合伙人級別的領導。該領導是希臘人，年紀很大，有著看起來特別牛逼的簡歷。這個領導有一個特點，就是不管下面的人怎么苦苦哀求要做代碼重構，他問的***個問題總是，這個代碼重構能帶來新的功能嗎?如果回答是否定的，直接槍斃掉。如果回答是肯定的，第二個問題是這些新功能非要代碼重構嗎?回答否定的話繼續斃掉。如果回答肯定，接下來會問到底有多少的程序是給新功能服務，有多少是在代碼重構呢?這個時候如果你的選擇是老老實實的說，大部分的程序只是代碼重構的話，基本上還是會被斃掉。總結來說只有新功能的投資，不愿意投資代碼重構。
這位領導以能deliver聞名，去哪里都可以多快好省的deliver很多的東西。這個領導還有一個特點，從來不在一個坑上待超過三年的。他走以后，很多時候整個隊伍就被爛代碼給坑了。另外，這個領導有個物理學的博士的學位。所以每次想起他來，我都覺得這個人肯定很懂熱力學第二定律，并且知道怎么樣去使用熱力學第二定律。
3.比較慶幸的一點是，我本人從來沒有攤上過這樣的領導。如果我們遵循熱力學第二定律的話，一個封閉的不維護的系統肯定是會越來越混亂的。為了保持系統的混亂程度不至于太糟糕，以至于無法收拾的話，我們就必須持續投入足夠多的新的低熵的東西。這個在代碼開發上來講，就是我們得有人專門去給代碼重構，讓代碼保持有序。
縱觀整個IT行業里，對于熱力學第二定律掌握的***的恐怕是Google。這從Google從代碼寫的風格到整個review的過程都可以看得出來。而且我們知道，Google這個公司從很小的時候就一直嚴格遵循這些原則了。很多人說，這樣做會妨礙創新，影響開發速度，那么為什么在Google里面這并沒有妨礙創新呢?
對熱力學第二定律掌握的很差的，但是公司依然很成功的是亞馬遜了。DevOps這種開發模式，讓開發人員24小時兼任救火隊員。我覺得這個是要對自己的系統的魯棒性多么的沒有信心才能做出來的決定啊。從某種程度上來講，亞馬遜的領導層對自己長期處于高熵狀態下運行系統是很有自知之明的。有自知之明其實不是壞事。問題是，為了維系這個高熵系統，亞馬遜總是需要犧牲一些人的利益的。這些人，當然是在底層當柴火一樣燒著的開發人員了。美其名曰有個名字叫做DevOps。
4.那么作為一個開發人員的你，應該做出什么樣的選擇呢?是希望讓代碼長期處于高熵值狀態，還是希望代碼時刻保持低熵呢?很多時候，這個問題其實不好回答。我想一個低熵值的代碼庫，如果偶爾需要增加熵值來完成一些商業上需要的東西，這并不難做到。一個高熵值的系統，如果也同樣需要再擠進去一些商業上需要的東西，后果是什么，就不可以預料了。
這些道理其實是很簡單的，我想沒有什么人不能理解。但是為什么在我們的IT行業里，有那么多的人依舊信奉永動機呢?又要馬兒跑又要馬兒不吃草的好事，只存在于夢里。但是我們的領導們很多時候的確是在追尋又要馬兒跑又要馬兒不吃草。而有些時候這種狀態又被冠冕堂皇的包裝在能夠deliver啊，或者DevOps的創新啊的光環下面。這樣一來，面子上看起來光鮮的東西，里子就未必了。
其實領導當然沒有那么傻。但是沒有那么傻卻依然這樣做，大致來說有幾種情況。***種是學習路易十四的我死后哪管他洪水滔天的精神。第二種情況是其實是有新的低熵的東西被冠冕堂皇的弄進來的。這就是那個24小時on call的你，你，還有你，這些DevOps們。代碼雖然熵值高，架不住那么多的DevOps伺候著啊，所以系統從客戶角度看起來，還是很穩定的。這個問題我就不展開了，各位看官，可以自己多腦補一下。
【本文為51CTO專欄作者“徐飛”的原創稿件，轉載請通過作者微信公眾號“飛總聊IT”獲取聯系和授權】
