《失控》讀書筆記范文

時間：2019-05-22 17:26:10 斯祺1212由分享

　　《失控》讀書筆記范文

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

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

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

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

　　順次假設：如果有另一個星球，其中的物質處于高度不穩定狀態，那么意味著這個星球中也存在生命，反之則不存在。(這一點已在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運行更順暢，也是另一個角度優化了用戶體驗。

　　熵與技術債

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

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

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

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