《失控》讀書筆記範文

《失控》讀書筆記範文

在文章開頭，我們先聊一個最讓我三觀震動的觀點：

熱力學第二定律說：熵增不可逆。它基本等同於在說：“這個宇宙註定走向冷寂，而我們束手無策，所以感謝上帝，讓我們處在宇宙熵適宜生命存在的時間裡。”可以說非常之冷酷。然而事實不完全是這樣。

如果只是一味地熵增，地球中的物質元素會越來越趨於穩定，地球會越來越安靜，就像太陽系的其他行星，充滿穩定的元素，變得死氣沉沉。但地球還是充滿了活躍物質和生命，迴圈往復，充滿活力。

熱力學的熵變將物質能量拉低，但生命的力量將物質能量提高，讓地球處在一種活躍的狀態。——科學家管這種力量叫“負熵”。

順次假設：如果有另一個星球，其中的物質處於高度不穩定狀態，那麼意味著這個星球中也存在生命，反之則不存在。(這一點已在NASA被證實)

更進一步：生命不斷繁衍下去，假設可以逐步佔據整個宇宙，那麼宇宙永遠不可能冷卻。

負熵這個概念應該寫在熱力學教材裡，這樣可以避免學這門課的盆友們心生沮喪。但如果真的寫上去，恐怕很多人會像我一樣在讀到這一段之後立刻要遠離熱力學了。

回到日常生活裡，熵這個概念被用在非常多的場合，比如設計熵、資訊熵、價值熵。聯絡“熵增不可逆”定律，很容易理解這樣措辭的道理。

而關於熵與生命，作者提到一些很有趣的道理，是很好的產品設計思路。

簡約高效與零bug妥協困境

作者從自動機器的起源開始討論這個問題。人類一開始做的機械非常簡單：一個輸入，一個輸出。到後來出現反饋調節，伺服電機，各種各樣的控制迴路，迴圈語句、遞迴迭代、神經網路模型等等。隨著系統越來越複雜，問題也越來越多。

一個系統很難免去bug。而修復bug過程本身引入更多bug的可能性。

我們做一個數據介面，介面本身很簡單，但為了監控介面資料正常、保證在任何特殊情況下不出錯很麻煩。1%的工作量解決了99%問題，剩下99%是為了規避掉那1%的異常。

為了解決問題，我們不得不修好有1%概率出現的補丁。但不能保證會不會有0.001%概率的問題不知道藏在哪裡。因為計算機語言是一階謂詞邏輯，在一個簡單的條件判斷中，我們可以在每個條件成立的分支上再次判斷“是否正確”，然後在每一個“否”的分支上繼續詢問：有多少種“否”的情況、每種情況該怎麼辦。這樣下去即使套無數層邏輯也還是不能cover 所有情況。

需求分析過程基本是因果論，它需要知道足夠多的原因，才能得到正確的結論。如果有些問題事先不知道，那結論中不可能包含它。因此，問題總是出在未知的地方，想要用邏輯覆蓋所有未知問題，實現徹底的閉環，不出任何

bug，就意味著有超級多的冗餘程式碼(更不用說因果論與程式語言自身就存在一些邏輯悖論)

簡約高效與零缺陷幾乎不可能共存，就像瀑布式軟體開發不能適應網際網路時代一樣。它需要產品與研發做出一些妥協，儘量簡約，並且規避大部分的bug。

機器的靈性

從零缺陷角度來說，採取直線型的簡單流程更容易實現。但是產品會不斷迭代，新需求越來越多，複雜不可避免，零缺陷就非常之難了。

軟體工程中有個概念，叫做模組間解耦合。儘量將流程拆解成一個個相對獨立的模組，減少模組間的耦合度，維持單個模組的通用性，同時也保證了系統的可拓展性。作者在書中舉了蜜蜂的例子。蜜蜂之間用一些簡單的訊號溝通，各司其職，有新的蜜蜂出生，也有蜜蜂因為各種各樣的原因死去。每隻蜜蜂的行動像機械一樣簡單，但整個社群穩定地存在且不斷地繁衍了下去。

但這樣的系統寫起來更復雜一些。它犧牲了一部分簡約，來方便迭代。它不太容易壞掉，或者說出了bug也不會導致整個系統癱瘓。但因為計算機系統是離散的、訊號式的，所以已知“a=1真” & “a=2真”，並不能判斷“a=1.5”是真還是假。所以問題往往出在一些意料之外的地方。比如阿里的公眾號曾經發過一篇文章，討論支付中偶發性出現1分錢差錯賬的問題是怎樣解決的。這個問題概率低到阿里的幾億使用者只有少數幾個人偶爾會遇到，以至於在產品上線前完全測不出這種問題。

作者把這種不完美但是更靈活的系統，叫做“有靈性的機器”，甚至與原始的生命做類比。而把那些無法預知的 bug 叫做“創造性”失靈。

“有靈性”的系統不能保證零缺陷，偶爾還鬧個么蛾子出來，但它更不容易壞掉，它不夠簡約，但方便迭代，總體來講更健壯一些。可以算一種還不錯的妥協結果了。

系統設計與使用者體驗

前面的內容基本只為系統設計考慮。換到使用者端去呢?在使用者體驗領域，講究的是，不要讓使用者思考，在恰當的場景為使用者提供恰當的內容，黏住使用者。至於方不方便迭代?使用者才不要管那麼多!

那前面的內容完全不適用了嗎?也不至於。在設計前端產品的時候換個角度：按場景做拆分，不同場景的內容放在不同頁面，有場景切換的時候，用連結從一個模組跳轉到另一個模組，也只要增加一些模組間的連線內容就好啦。

網際網路時代體驗至上，做產品，第一位要考慮使用者體驗，體驗是王道，體驗好才有使用者，為了使用者體驗要精益求精，一切都要為體驗讓路。但事實上，某個按鈕放在上面還是下面，某某表單用一個頁面還是兩個，很多時候一半使用者喜歡A另一半使用者喜歡B，這時就不能再用體驗做唯一標準了。

現在使用者體驗已經是基礎標配，而非高不可攀，我們大可以在此之上增加一些要求。如果某種設計方式在不傷害體驗的前提下，能讓研發節約20%工作量，不是更有價值嗎?如果這樣可以讓系統結構更合理、app執行更順暢，也是另一個角度優化了使用者體驗。

熵與技術債

我們聊資訊熵，是說限制各種無意義的內容充斥網路，我們最容易接觸到的通常是一些沒什麼用的資訊。降低某一部分資訊熵的代價幾乎要超過資訊本身的價值。

而設計熵高的產品，會更復雜、更不容易讓人理解、美得讓人感官疲憊;設計熵理論涉及到仿生學，也與生命產生聯絡。

軟體工程領域有個詞叫技術債，也可以當做一種熵。

如果說降低熵的方式，是生命的力量。那減緩熵增的方式，就是讓物質變得更像生命。至於非常像生命的時候會發生什麼，那就是另一個問題了。