認真讀完一本名著後，你有什麼總結呢？不妨坐下來好好寫寫讀書筆記吧。你想好怎麼寫讀書筆記了嗎？下面是小編幫大家整理的《失控》讀書筆記範文，僅供參考，大家一起來看看吧。
在文章開頭，我們先聊一個最讓我三觀震動的觀點：
熱力學第二定律說：熵增不可逆。它基本等同於在說：“這個宇宙註定走向冷寂，而我們束手無策，所以感謝上帝，讓我們處在宇宙熵適宜生命存在的時間裏。”可以說非常之冷酷。然而事實不完全是這樣。
如果只是一味地熵增，地球中的物質元素會越來越趨於穩定，地球會越來越安靜，就像太陽系的其他行星，充滿穩定的元素，變得死氣沉沉。但地球還是充滿了活躍物質和生命，循環往復，充滿活力。
熱力學的熵變將物質能量拉低，但生命的力量將物質能量提高，讓地球處在一種活躍的狀態。——科學家管這種力量叫“負熵”。
順次假設：如果有另一個星球，其中的物質處於高度不穩定狀態，那麼意味着這個星球中也存在生命，反之則不存在。(這一點已在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運行更順暢，也是另一個角度優化了用戶體驗。
熵與技術債
我們聊信息熵，是說限制各種無意義的內容充斥網絡，我們最容易接觸到的通常是一些沒什麼用的信息。降低某一部分信息熵的代價幾乎要超過信息本身的價值。
而設計熵高的產品，會更復雜、更不容易讓人理解、美得讓人感官疲憊;設計熵理論涉及到仿生學，也與生命產生聯繫。
軟件工程領域有個詞叫技術債，也可以當做一種熵。
如果說降低熵的方式，是生命的力量。那減緩熵增的方式，就是讓物質變得更像生命。至於非常像生命的時候會發生什麼，那就是另一個問題了。