《失控》讀書筆記范文

1、范文在文章開頭，我們先聊一個最讓我三觀震動的觀點：熱力學第二定律說：熵增不可逆。它基本等同于在說：“這個宇宙注定走 向冷寂，而我們束手無策，所以感謝上帝，讓我們處在宇宙熵適宜生命存在的 時間里?！笨梢哉f非常之冷酷。然而事實不完全是這樣。如果只是一味地熵增，地球中的物質元素會越來越趨于穩(wěn)定，地球會越來 越安靜，就像太陽系的其他行星，充滿穩(wěn)定的元素，變得死氣沉沉。但地球還 是充滿了活躍物質和生命，循環(huán)往復，充滿活力。熱力學的熵變將物質能量拉低，但生命的力量將物質能量提高，讓地球處 在一種活躍的狀態(tài)?？茖W家管這種力量叫“負熵”。順次假設：如果有另一個星球，其中的物質處于高度不穩(wěn)定狀態(tài)，那么意味著這個

2、星球中也存在生命，反之則不存在。（這一點已在NAS徽證實）更進一步：生命不斷繁衍下去，假設可以逐步占據整個宇宙，那么宇宙永遠不可能冷卻。負熵這個概念應該寫在熱力學教材里，這樣可以避免學這門課的盆友們心生沮喪。但如果真的寫上去，恐怕很多人會像我一樣在讀到這一段之后立刻要遠離熱力學了。回到日常生活里，熵這個概念被用在非常多的場合，比如設計熵、信息熵、價值熵。聯(lián)系“熵增不可逆”定律，很容易理解這樣措辭的道理。而關于熵與生命，作者提到一些很有趣的道理，是很好的產品設計思路。簡約高效與零bug妥協(xié)困境作者從自動機器的起源開始討論這個問題。人類一開始做的機械非常簡單：一個輸入，一個輸出。到后來出現(xiàn)反饋調節(jié)

3、，伺服電機，各種各樣的控制回路，循環(huán)語句、遞歸迭代、神經網絡模型等等。隨著系統(tǒng)越來越復雜，問題也越來越多。一個系統(tǒng)很難免去bug。而修復bug過程本身引入更多bug的可能性。我們做一個數(shù)據接口，接口本身很簡單，但為了監(jiān)控接口數(shù)據正常、保證在任何特殊情況下不出錯很麻煩。1%的工作量解決了99%問題，剩下99%是為了規(guī)避掉那1%的異常。為了解決問題，我們不得不修好有1%概率出現(xiàn)的補丁。但不能保證會不會有 %概率的問題不知道藏在哪里。因為計算機語言是一階謂詞邏輯，在一個簡單的條件判斷中，我們可以在每個條件成立的分支上再次判斷“是否正確”，然后在每一個“否”的分支上繼續(xù)詢問：有多少種“否”的情況、每種

4、情況該怎么辦。這樣下去即使套無數(shù)層邏輯也還是不能cover 所有情況。需求分析過程基本是因果論，它需要知道足夠多的原因，才能得到正確的結論。如果有些問題事先不知道，那結論中不可能包含它。因此，問題總是出在未知的地方，想要用邏輯覆蓋所有未知問題，實現(xiàn)徹底的閉環(huán)，不出任何bug,就意味著有超級多的冗余代碼（更不用說因果論與編程語言自身就存在一些邏輯悖論）簡約高效與零缺陷幾乎不可能共存，就像瀑布式軟件開發(fā)不能適應互聯(lián)網時代一樣。它需要產品與研發(fā)做出一些妥協(xié)，盡量簡約，并且規(guī)避大部分的bug。機器的靈性從零缺陷角度來說，采取直線型的簡單流程更容易實現(xiàn)。但是產品會不斷迭代，新需求越來越多，復雜不可避免，

5、零缺陷就非常之難了。軟件工程中有個概念，叫做模塊間解耦合。盡量將流程拆解成一個個相對獨立的模塊，減少模塊間的耦合度，維持單個模塊的通用性，同時也保證了系統(tǒng)的可拓展性。作者在書中舉了蜜蜂的例子。蜜蜂之間用一些簡單的信號溝通，各司其職，有新的蜜蜂出生，也有蜜蜂因為各種各樣的原因死去。每只蜜蜂的行動像機械一樣簡單，但整個社群穩(wěn)定地存在且不斷地繁衍了下去。但這樣的系統(tǒng)寫起來更復雜一些。它犧牲了一部分簡約，來方便迭代。它不太容易壞掉，或者說出了 bug 也不會導致整個系統(tǒng)癱瘓。但因為計算機系統(tǒng)是離散的、信號式的，所以已知“ a=1 真” & “ a=2 真”，并不能判斷“a=”是真還是假。所以問題往往出

6、在一些意料之外的地方。比如阿里的公眾號曾經發(fā)過一篇文章，討論支付中偶發(fā)性出現(xiàn)1 分錢差錯賬的問題是怎樣解決的。這個問題概率低到阿里的幾億用戶只有少數(shù)幾個人偶爾會遇到，以至于在產品上線前完全測不出這種問題。作者把這種不完美但是更靈活的系統(tǒng)，叫做“有靈性的機器”，甚至與原始的生命做類比。而把那些無法預知的 bug 叫做“創(chuàng)造性”失靈?！坝徐`性”的系統(tǒng)不能保證零缺陷，偶爾還鬧個幺蛾子出來，但它更不容易壞掉，它不夠簡約，但方便迭代，總體來講更健壯一些。可以算一種還不錯的妥協(xié)結果了。系統(tǒng)設計與用戶體驗前面的內容基本只為系統(tǒng)設計考慮。換到用戶端去呢?在用戶體驗領域，講究的是，不要讓用戶思考，在恰當?shù)膱鼍盀?/p>

7、用戶提供恰當?shù)膬热荩ぷ∮脩?。至于方不方便迭?用戶才不要管那么多!那前面的內容完全不適用了嗎?也不至于。在設計前端產品的時候換個角度：按場景做拆分，不同場景的內容放在不同頁面，有場景切換的時候，用鏈接從一個模塊跳轉到另一個模塊，也只要增加一些模塊間的連接內容就好啦。互聯(lián)網時代體驗至上，做產品，第一位要考慮用戶體驗，體驗是王道，體驗好才有用戶，為了用戶體驗要精益求精，一切都要為體驗讓路。但事實上，某個按鈕放在上面還是下面，某某表單用一個頁面還是兩個，很多時候一半用戶喜歡A另一半用戶喜歡B,這時就不能再用體驗做唯一標準了。現(xiàn)在用戶體驗已經是基礎標配，而非高不可攀，我們大可以在此之上增加一些要求。如果某種設計方式在不傷害體驗的前提下，能讓研發(fā)節(jié)約20%工作量，不是更有價值嗎 ?如果這樣可以讓系統(tǒng)結構更合理、 app 運行更順暢，也是另一個角度優(yōu)化了用戶體驗。熵與技術債我們聊信息熵，是說限制各種無意義的內容充斥網絡，我們最容易接觸到的通常是一些沒什么用的信息。降低某一部分信息熵的代價幾乎要超過信息本身的價值。而設計熵高的產品，會更復雜、更不容易讓人理解