《失控》读书笔记范文
《失控》读书笔记范文
在文章开头，我们先聊一个最让我三观震动的观点：
热力学第二定律说：熵增不可逆。它基本等同于在说：“这个宇宙注定走向冷寂，而我们束手无策，所以感谢上帝，让我们处在宇宙熵适宜生命存在的时间里。”可以说非常之冷酷。然而事实不完全是这样。
如果只是一味地熵增，地球中的物质元素会越来越趋于稳定，地球会越来越安静，就像太阳系的其他行星，充满稳定的元素，变得死气沉沉。但地球还是充满了活跃物质和生命，循环往复，充满活力。
热力学的熵变将物质能量拉低，但生命的力量将物质能量提高，让地球处在一种活跃的状态。——科学家管这种力量叫“负熵”。
顺次假设：如果有另一个星球，其中的物质处于高度不稳定状态，那么意味着这个星球中也存在生命，反之则不存在。(这一点已在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运行更顺畅，也是另一个角度优化了用户体验。
熵与技术债
我们聊信息熵，是说限制各种无意义的内容充斥网络，我们最容易接触到的通常是一些没什么用的信息。降低某一部分信息熵的代价几乎要超过信息本身的价值。
而设计熵高的产品，会更复杂、更不容易让人理解、美得让人感官疲惫;设计熵理论涉及到仿生学，也与生命产生联系。
软件工程领域有个词叫技术债，也可以当做一种熵。
如果说降低熵的方式，是生命的力量。那减缓熵增的方式，就是让物质变得更像生命。至于非常像生命的时候会发生什么，那就是另一个问题了。