第7-12章好像和面向对象没多大关系，内容也有点水了。

第13章（函数式语言是怎样工作的）写的不错。

面向对象的起源可以追溯到挪威的两名技术人员在1967年开发的 Simula 67 编程语言。之后，任职于美国施乐公司的艾伦•凯率领的团队开发了 Smaltalk，沿用了 Simula 67 语言的结构，确立了面向对象的概念。除此之外，凯在 IT领域还做出了很多贡献，比如开发出图形用户界面（Graphical User Interface,GUI提出作为现代笔记本电脑原型的“DynaBook设想”等。
“预测未来最好的方法就是创造它。”（The best way to predictthe future is to invent it.）据说这句名言是公司高层追问研究内容的未来走向时，凯给出的回答。想必也只有提出了诸多创新性的技术概念的凯，才能讲出这样的名言吧。

NODM 由网络（Network）、开源（Open source）、小型化（Down-sizing）和多媒体（MultiMedia）这4个单词的首字母组成“，该词在日本20世纪 90年代前半期的 IT领域广为流行。不过，随着互联网的普及，NODM 所代指的技术都逐渐成了通用技术，因此该词自然也就不再被使用了。

好莱坞原则一词可以用来表示这种框架结构的特征。在好菜坞，电影制作者对演员说“Don't call us, we will call you”（不要给我们打电话，我们会给你打电话）。

这些管理方法之所以如此失败，是因为使用它们的管理人员不理解软件项目的基本原理。这一原理被称为项目管理的铁十字，约束着所有项目必须做出权衡，无法突破。
质量、速度、成本、完成，你只能任选3个，没法4个全要。可以要求高质量、快速、低成本，这样的话项目就做不完。也可以要求低成本、快速地完成项目，那样的话质量一定不会好。

布鲁克斯定律'指出：为延迟的项目增加人手反而会使它更加延迟。

一种非常适用于大型任务的技术是三元估算。这种估算由3个数组成，这3个数分别对应最佳情况、正常情况和最坏情况。这些数都是对信心的估计：最坏情况是指你有95%的信心认为能完成该任务的时间，正常情况仅具有50%的信心，最佳情况仅具有5%的信心。

故事遵循一组简单的指导原则，这组原则的首字母缩写是 INVEST。
•|：独立（Independent）。用户故事彼此互相独立。这意味着在实现它们时不必遵守特定的顺序。例如登录不是必须在退出之前实现。
• N：可协商（Negotiable）。这是我们不在卡片上写下所有细节的另一个原因：我们希望开发人员和业务人员之间可以就这些细节进行协商。
• V：有价值（Valuable）。用户故事必须对业务具有明确且可量化的价值。
• E：可估算（Estimable）。用户故事必须足够具体，以允许开发人员进行估算。
• S：小（Small）。用户故事不应大于一到两个开发人员可以在一个选代中实现的工作量。
• T：可测试（Testable）。业务部门应该能够提出用户故事的测试标准，通过这些测试就能表明用户故事己经完成。

TDD 可以描述为以下3条简单的规则。
• 先编写一个因为缺乏生产代码而失败的测试，然后才能编写生产代码。
• 只允许编写一个刚好失败的测试——编译失败也算。
• 只允许编写刚好能使当前失败测试通过的生产代码。

肯特•贝克很久以前就提出了敏捷的4个价值观：勇气、沟通、反馈和简单。

人使用和控制工具，不能让工具控制和使用人。

分解、合并和穿刺
合并故事很简单。你可以将几张故事卡夹在一起，把它们当作一个故事对待，只需将所有故事点相加即可。
拆分故事会更有趣，因为你需要保持故事的 INVEST 原则。
穿刺是一个元故事，或者叫“用于估算故事的故事”。之所以称为穿刺，是因为我们经常需要开发一个长而很薄的切片，来打穿系统的所有层。

QA病
然而，这还不是最糟糕的。把QA工作放在流程的尾端还会带来更糟糕的问题。如果QA处于流程尾端，组织如何知道他们是否做好了自己的工作？很简单，看他们能发现多少缺陷。如果 QA 发现了很多缺陷，他们显然做得很好，QA 经理可以吹嘘自己团队发现了多少缺陷，以此作为 QA 团队尽职尽责的明确证据。
于是，发现缺陷被认为是好事。
还有谁能从这些缺陷中获益呢？老程序员有这样的说法：“你可以给我设定任何交货期限，只要别要求软件正常工作就行。”还有其他人能从缺陷中获益吗？那就是那些需要去满足交货最后期限的开发人员。
什么话都不用说，什么协议都不用写，双方都明白，他们都能从缺陷中受益。一个缺陷的“黑市经济”出现了。这种“疾病”渗透到许多组织中，哪怕暂时还不致命，这种“疾病”毫无疑问使组织逐渐虚弱。

在豆瓣上搜索这本书没有找到
原来这本《微信读书》上的书没有出版，自然也没有ISBN，所以并没有在豆瓣上查到

感觉不像是程序员，倒像是产品经理，还是偏算法端的
书中人物臧叔有点像刘润采访过的“网约车教父”臧勤
作者非常喜欢高度地图和享快打车这两款APP

全书出现最多的一句话：“一切都是最好的安排”
充满着互联网黑话，错别字有点多
最后的结尾也太突然了

这套跑车背后的逻辑就是必须要形成接单闭环。

什么样的预约单或者首单算得上是个好单？我的答案是离家近、开得快、金额高、连环单。

有的人出生在罗马，有的人一生在通往罗马的路上。

确实从概率上来讲，不顺是必然，太顺只是偶然。

心中若有阳光，窗外便是灿烂。

只有脑力的方向正确了，体力的拼搏才会有价值。

从解决问题的角度讲设计模式非常好，特别是两个解决统一问题的设计模式一起讲。

有一个小错误：P67 setUp()写成了steUp()

敏捷宣言
我们一直在实践中揭示更好的软件开发方法，身体力行的同时也帮助他人。
由此，我们建立了如下价值观：
个体和互动 优先于 流程和工具
工作的软件 优先于 详尽的文档
客户合作 优先于 合同谈判
响应变化 优先于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。

面向对象设计的原则
SRP 单一职责原则 就一个类而言，应该有且仅有一个引起它变化的原因。
OCP 开放-封闭原则 软件实体（类、模块和函数等）应可以扩展，但不可修改。
LSP 里氏替换原则 子类型必须能替换掉它们的基本类型。
ISP 接口隔离原则 不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
DIP 依赖倒置原则 抽象不应该依赖于细节。细节应该依赖于抽象。
REP 重用发布等价原则 重用的粒度就是发布的粒度。
CCP 共同重用原则 一个包中的所有类应该是共同重用的。如果重用包中的一个类，那么就要重用包中的所有类。相互之间没有紧密联系的类不应该在同一个包中。
CRP 共同封闭原则 一个包中所有的类对同一类性质的变化应该是共同封闭的。一个变化若对一个包有影响，就会影响到包中所有的类，但不会影响到其他的包造成任何影响。
ADP 无依赖原则 在包的依赖关系中不允许存在环。细节不应该有其他依赖关系。
SDP 稳定依赖原则 朝着稳定的方向进行依赖。
SAP 稳定抽象原则 一个包的抽象程度应该和其他的保持一致。

很多团队迷失在追求文档而非软件上。这通常是个巨大的错误。有条简单的规则称为“文档的马丁第一原则”，意在防止此类错误发生：
除非文档紧急且重要，否则不要写。

“大千世界，唯一稀缺的是人类的注意力。”——凯文·凯利（KK）

每个软件模块都有三项职责。第一项职责是运行所完成的功能。这是该模块得以存在的原因。第二项职责是它要应对变化。几乎所有的模块在它们的生命周期中都要变化，开发者有责任保证这种改变应该尽可能简单。一个难以改变的模块是拙劣的，即便能够工作，也需要对它进行修正。第三项职责是要和读的人沟通。对该模块不熟悉的开发人员应该能够轻松地阅读并理解它。一个不能沟通的模块也是拙劣的，同样需要对它进行修正。

在 SRP 的语境中，我们把职责定义为“变化的原因”（a reason for change）。如果你有超过一个的动机去改变一个类，那么这个类就具有多种职责。有时，我们很难注意到这一点。我们习惯于以组（group）的形式去考虑职责。

许多开发人员可能会对“合理假设”的行为这一概念惴惴不安。怎样才能知道客户真正的要求呢？有一种技术可以让这些合理的假设明确下来，从而支持LSP。这种技术就是基于契约的设计（Design By Contract, DBC）。梅耶（Bertrand Meyer）对此做过阐述［Meyer1978, p.331］。
使用 DBC，类的作者明确表达出对于这个类的契约。客户端的代码可以通过契约获悉可以依赖的行为方式。契约是通过为每一个方法声明前置条件（precondition）和后置条件（postcondition）来制定的。要让一个方法得以执行，前置条件必须为真。执行完毕后，这个方法要保证后置条件为真。
按照梅耶（Meyer）的阐述，派生类的前置条件和后置条件的规则如下：
在重新声明派生类中的方法（routine，例程）时，只能使用相等或者更弱的前置条件来替换原始的前置条件，只能使用相等或者更强的后置条件来替换原始的后置条件。［Meyer97,p.573］
换句话说，当通过基类的接口使用对象时，用户只知道基类的前置条件和后置条件。
因此，派生类对象不能期望这些用户遵从比基类更强的前置条件。也就是说，他们必须接受基类可以接受的一切。同时，派生类必须和基类的所有后置条件一致。也就是说，它们的行为方式和输出不能违反基类已经确立的任何限制。基类的用户不能被派生类的输出干扰。

包的设计原则
粒度：包的内聚性原则
重用发布等价原则（REP）
可以复用的粒度就是可以发布的粒度。
共同重用原则（CRP）
在包中的类可以一起被复用。如果你复用包中的某一个类，那么就要复用包中的
所有类。
共同封闭原则（CCP）
一个包中的类对于同一类型的变化应该是共同封闭的。对于一个包的更改会影响
到该包中的所有类，而不会影响到其他包。
稳定性：包耦合性的原则
无环依赖原则（ADP）
包之间的依赖关系图中不应该存在环形。
稳定依赖原则（SDP）
向着稳定的方向依赖。
稳定抽象原则（SAP）
包的抽象程度应该和其稳定程度一致。