程式員修煉的務實哲學

雲栖号資訊：【 點選檢視更多行業資訊

】

在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！

軟體的熵

雖然軟體開發不受絕大多數實體法則的限制，但我們無法躲避來自熵的增加的重擊。熵是一個實體學術語，它定義了一個系統的“無序”總量。不幸的是，熱力學法則決定了宇宙中的熵會趨向最大化。當軟體中的無序化增加時，程式員會說“軟體在腐爛”。有些人可能會用更樂觀的術語來稱呼它，即“技術債”，潛台詞是說他們總有一天會償還的——恐怕不會還了。

不過不管叫什麼名字，債務和腐爛都可能失控地蔓延開。

有很多因素會導緻軟體腐爛。最重要的一個似乎是項目工作中的心理性狀态，或者說文化。即使是一個單人團隊，你的項目的心理性狀态也是個非常脆弱的東西。即使有最合理的計劃和最佳的人員，項目還是可能在生命周期中逐漸荒廢、腐爛。但也有一些項目在經曆了巨大的困難、持續不斷的挫折之後，成功地對抗了天然的無序化傾向，走出了困境。

是什麼造成了差異？

在城市中心，有些建築幹淨漂亮，而另一些則破落不堪。為什麼會這樣？一些犯罪和城市衰敗領域的研究人員發現了一個有趣的觸發機制，隻需一樣東西就能非常迅速地把一幢幹淨完好的宜居建築變成一個破敗的廢棄物。

一扇破窗。

一扇破損的窗戶，隻要一段時間不去修理，建築中的居民就會潛移默化地産生一種被遺棄的感覺——當權者不關心這幢建築的感覺。然後，其他的窗戶也開始損壞，居民開始亂丢廢物，牆上開始出現塗鴉，建築開始出現嚴重的結構性損壞。在一段看上去很短的時間内，建築的損壞程度就足以打消業主們想修好它的期望，被遺棄的感覺最終變成了現實。為何造成這樣的影響？心理學家的研究 1 表明，絕望是會傳染的，就像狹窄空間中的流感病毒。無視一個明顯損壞的東西，會強化這樣一種觀念：看來沒有什麼是能修好的，也沒人在乎，一切都命中注定了。所有的負面情緒會在團隊成員間蔓延，變成惡性循環。

提示　不要放任破窗

不要擱置“破窗”（糟糕的設計、錯誤的決定、低劣的代碼）不去修理。每發現一個就趕緊修一個。如果沒有足夠的時間完全修好，那麼就把它釘起來。也許你可以注釋掉那些糟糕的代碼，顯示一行“尚未實作”的資訊，或用假資料先替代一下。采取行動，預防進一步的損害發生，表明一切盡在你的掌握中。

現在我們了解了一旦窗戶開始破裂，運轉良好的幹淨系統會迅速惡化。還有一些其他因素會導緻軟體腐爛，我們将在别處探讨，但與其他任何因素相比，漠視會加速腐爛的過程。

你或許會覺得，沒人有時間來來回回清理項目中所有的碎玻璃。如果你真這麼想，勸你還是趁早多想想怎麼料理這個項目的後事，或是直接離開是非之地。不要讓熵赢得勝利。

先勿傷害

多年以前，Andy 認識一個土豪。他的房子富麗堂皇，屋子裡擺滿了無價的古董，到處陳列着精美的藝術品。有一天，一張挂毯因為離客廳壁爐太近而着火了。消防員奮勇沖進去救民于水火，當然主要是火。但是在把巨大的水管拖進屋子前，他們停了下來——盡管裡面火勢緊急——毅然選擇先在前門和火源之間鋪上墊子，因為覺得水管太髒。

他們不想弄壞地毯。

現在聽起來這很偏激。消防部門的首要任務當然是滅火，何必管過程中的那些附帶損害呢？但是他們在清醒地評估了形勢後，出于對自己控制這場火勢能力的絕對自信，還是盡力兼顧了不對财物造成不必要的毀害。這也是軟體開發中應該遵循的方法：不要隻是因為一些東西非常危急，就去造成附帶損害。破窗一扇都嫌太多。

一扇破窗——一段設計糟糕的代碼，一個讓團隊在整個項目周期内都必須要遵守的糟糕管理決定——就是一切衰退的開始。如果你發現自己正處在有幾扇破窗的項目中，就非常容易陷入這樣的想法——“反正代碼所有其他部分都是一坨屎，我隻是随大流而已。”項目運作在這個時間點前是不是一直良好并不重要。在最初啟發“破窗理論”的實驗中，一輛廢棄的汽車完好無損地停放了一個星期。但是一旦有一塊玻璃被打破，這輛車在幾個小時内就會被扒光并翻了個底朝天。

出于同樣原因，如果身處一個健康團隊，你們項目的代碼如此完美——編寫清晰、設計優良、簡潔優雅——你就會傾向于格外地小心，不把它弄糟。就像那些消防員一樣，即使屋内火勢熊熊（截止時限、發行日期、銷售示範，等等），你也不想成為第一個弄亂它、造成附帶損害的人。一定要告訴自己，“不要打破窗戶。”

石頭做的湯和煮熟的青蛙

有三個戰場歸途中的士兵饑腸辘辘。他們看到前方有一座村莊，頓時重整精神——他們覺得村民們會給口飯吃。可是當他們抵達那裡時，卻發現四處門窗緊閉。多年戰亂下，村民們食物短缺，僅有的存糧都藏了起來。

士兵們沒有氣餒，他們燒了一鍋水，小心翼翼地在裡面放了三塊石頭。詫異的村民們都跑出來圍觀。

“這叫石頭湯。”士兵們解釋道。“你們在湯裡隻放這個？”村民們問道。“對——不過有人說如果加點胡蘿蔔味道會好一些……”一個村民轉身跑回了家，從自己的窖藏中拎來了一筐胡蘿蔔。

幾分鐘之後，村民們又問道“這就可以了嗎？”

“可以了，”士兵們說道，“加幾個洋芋或許更有味道。”另一個村民聽到後跑開了。

在接下來的一個小時内，士兵們列出了更多食材：牛肉、韭菜、鹽及各種香料，說能讓湯做得更加鮮美。每次都有不同的村民跑回去取來自己的私藏。

最後，他們煮了一大鍋熱氣騰騰的湯。士兵們把湯裡的石頭扔掉，和整個村子的村民一起分享了一頓美餐，這是他們所有人幾個月以來吃的第一頓飽餐。

石頭湯這個故事講述了很多道理。村民被士兵騙了，士兵利用了村民的好奇心來擷取食物。不過更重要的是，士兵充當了催化劑的角色，将村民們組織了起來。這樣他們才能聚在一起做出他們無法單獨做到的事情——一項協作的成果。最後所有人都是赢家。

從現在開始，你要考慮仿效這些士兵。

你可能處在這樣一種狀況下——清楚地知道需要做些什麼，以及怎樣去做。整個系統就在你的眼前——你知道這樣做就對了。但當你為做整件事去征求意見的時候，見到的往往是推脫和茫然的眼神。人們想成立一個委員會，然後申請預算，之後事情會變得異常繁雜。每個人都會守着自己的一畝三分田。有時我們稱之為“籌備期的勞累”。這個時候，就該拿出石頭了——找出你合理的請求，然後不斷完善。一旦有成果産出，展示給人們看，讓他們大吃一驚。現在可以用上“當然了，它還可以更好，隻要我們再加點……”這句話，而且要假裝你并不在意。這時先坐下來，等他們開始問你要不要加些你原本想要的功能。人們都覺得，加入一個推進中的成功項目更容易一些。因為隻要一窺未來，大家就能團結在一起。

提示　做推動變革的催化劑

村民們的角度

換個角度來看，石頭湯的故事講述的是一個溫和漸進的騙局。因為過于将注意力集中在石頭上，村民們忘卻了石頭外的世界，這很像我們每天陷入俗事纏身的狀态。

項目進展緩慢，完全失去了控制——這是很常見的症狀。大多數軟體災難都始于微不足道的小事，項目的拖延也是一天天累積而成的。系統一個特性接一個特性地偏離規範，一個接一個的更新檔加到代碼上，最終原始代碼無影無蹤。往往就是一件件小事的累積破壞了團隊和士氣。

提示　牢記全景

老實說，下面這件事其實我們從來都沒試過。隻是聽“有人”說過，如果你抓住一隻青蛙，把它扔進沸水中，它立刻就會跳出來。但是，如果你把青蛙放在一鍋冷水中，然後緩慢地加熱，青蛙就不會意識到水溫在緩慢上升，直到它們被煮熟。

注意，青蛙的案例和話題 3：軟體的熵讨論的破窗問題不同。破窗理論中，人們失去打敗熵的鬥志是因為他們覺得沒其他人在乎。而青蛙僅僅隻是未察覺到變化。

不要學寓言裡的青蛙，永遠留意着大局，持續不斷地審視你身邊發生的事情，而不要隻專注于你個人在做的事情。

挑戰

在審閱第一版的草稿時，John Lakos 提出了這樣一個問題：士兵們一步步地欺騙着村民，但他們作為催化劑促成的變化對大家都好。然而，你一步步地欺騙青蛙，卻是在傷害它。你在催生變化的時候，能判别是在做石頭湯還是青蛙湯嗎？這個決定是出于主觀還是客觀？不要看，馬上回答，你頭頂的天花闆上有幾盞燈？屋子裡一共有幾盞燈？有多少人？有沒有發現什麼東西有違和感，感覺它們不應該屬于這裡？這是一個情景感覺的練習，從童子軍到海豹突擊隊，人們都在練習這種技巧。先養成仔細觀察周圍環境的習慣，然後在項目中這樣做。

【雲栖号線上課堂】每天都有産品技術專家分享！

課程位址：

https://yqh.aliyun.com/zhibo

立即加入社群，與專家面對面，及時了解課程最新動态！

【雲栖号線上課堂 社群】

https://c.tb.cn/F3.Z8gvnK

原文釋出時間：2020-05-18

本文作者：Andrew Hunt David Thomas

本文來自：“

InfoQ

”，了解相關資訊可以關注“

”