【张建飞：《程序员的底层思维》】看书笔记

简介

本书涵盖程序员应知应会的16种思维能力，共18章，分为三部分。第一部分主要介绍抽象思维、逻辑思维、结构化思维、批判性思维、维度思维、分类思维、分治思维、简单思维，以及成长型思维等解决日常问题的基础思维能力。第二部分结合软件行业的特点，主要介绍解耦思维、契约思维、模型思维、工具化思维、量化思维、数据思维，以及产品思维等专业思维能力。第三部分主要是对上述思维能力的综合运用实践。

第一部分 基础思维能力

01 抽象思维

1.1 抽象 = 抽离 + 具象

1. 抽象是从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过程。

“抽”就是抽离，“象”就是具象。从字面上理解抽象，抽象的过程就是从“具象”事物中归纳共同特征，“抽取”得到一般化的概念的过程。

1.2 抽象是哲学思维的基础

1. 西方哲学诞生于古希腊，古人仰望星空，开始思索世界本源的问题，从具象的“水、火、气”到毕达哥拉斯的“数”，再到德谟克利特的原子论，以及柏拉图的“理念世界”。

1.3 语言的抽象性

1. 我们只能通过语言表达抽象的概念，并进行逻辑判断和推理。

1.4 软件设计中的抽象

1.4.1 面向对象的核心是抽象

1. 抽象是软件设计的核心，特别是在面向对象设计中，如果没有好的抽象概念，就不可能设计和编写出好的面向对象（Object Oriented, OO）程序。
   1. OOA是一种分析方法，这种方法利用从问题域的词汇表中找到的类和对象来分析需求。
   2. 包括面向对象分解的过程和表示法，这种表示法用于展现被设计系统的OOD是一种设计方法，逻辑模型和物理模型、静态模型和动态模型。
   3. OOP是一种实现方法，在这种方法中，程序被组织成许多组相互协作的类，类之间会通过继承、组合、使用形成一定的层次结构。

1.4.2 抽象设计的评判标准

1. 抽象设计的评判标准包括耦合性、内聚性、充分性和完整性。
   1. 耦合性：强耦合使系统变得复杂，因为如果某个模块与其他模块过度相关，它就难以独立地被理解、变化或修正，通过降低耦合性，可以降低复杂性。
   2. 内聚性：内聚测量了单个模块（类、包、组件）内各个元素的联系程度。
   3. 充分性：所谓充分，是指类或模块应该记录某个抽象设计足够多的特征，从而允许有意义的交互，否则将使组件变得无用。
   4. 完整性：完整是指类或模块的接口记录了某个抽象全部有意义的特征。

1.4.3 抽象缺失之基础类型偏执

基础类型偏执（Primitive Obsession）是Martin Fowler在《重构：改善既有代码的设计》一书中提到的一种典型的代码“坏味道”，意思是我们使用了太多的基础类型，导致有些应该被抽象成实体类的概念，却以基础类的形式散落在代码各处，这是一种典型的抽象缺失。

1.4.4 抽象缺失之重复代码重复代码是典型的代码坏味道，其本质问题就是抽象缺失。

1.4.5 抽象设计要完整

好的抽象设计是内聚而完整的。

1.4.6 不要为了抽象而抽象

抽象的前提是共性抽取，抽象思维之所以如此重要，因为它涉及软件设计的方方面面，小到一个方法、一个类的设计，大到系统架构。

1.5 抽象的层次性

1.5.1 对抽象层次的权衡

1. 抽象层次越高，内涵越小，外延越大，扩展性越好；反之，抽象层次越低，内涵越大，外延越小，扩展性越差，但语义表达能力越强。

抽象层次性主要体现在概念的内涵和外延上，而这种层次性基本可以体现在任何事物上。

2. 对抽象层次的权衡是对我们设计能力的考验，要根据业务的需要，选择合理的抽象层次，既不能太高，也不能太低。

1.5.2 软件中的分层抽象

1. 越是复杂的问题越需要分层抽象，分层是分而治之，抽象是对问题域的合理划分和概念语义的表达。

不同层次提供不同的抽象结果，下层对上层隐藏实现细节，通过这种层次结构，我们才有可能应对像网络通信、云计算等超级复杂的问题。

1.5.3 强制类型转换中的抽象层次问题

1. 强制类型转换意味着抽象层次有问题，可以通过提升抽象层次来解决。

1.5.4 抽象层次一致性原则

1. 抽象层次要保持一致性，即要遵循SLAP，一致性可以减少混乱和降低理解成本。

SLAP强调每个方法中的所有代码都处于同一级抽象层次。

1.6 锻炼抽象思维能力

1. 多阅读、勤总结、命名训练、领域建模训练等，都可以提升抽象能力。

02 逻辑思维

2.1 逻辑就是关系

1. 逻辑就是关系，是思维的规律和规则。
2. 逻辑思维基本包含3个方面的要素：概念、判断、推理。
   1. 概念是思维的基本单位，是反映事物本质属性或特有属性的思维形式。
   2. 判断（也叫作命题）是推理的基础，一个判断就是一个断言（Assert），它断定了一个事情是这样或者不是这样。
   3. 推理（也叫作论证）是由一个或几个判断推出另一判断的思维形式。

2.2 逻辑三要素之概念

2.2.1 概念要明确且清晰

1. 对概念的明晰和定义是我们设计过程中的重要内容。
2. 在一个领域内，如果一个系统的核心概念的定义出现了问题，可能会给上层的业务带来毁灭性的打击。

2.2.2 制定团队通用语言

1. 一个团队只有具有统一的语言概念基础，并划分了清晰的边界，才能更好地沟通协作。
2. 文档和代码中的核心概念只有保持一致，才会具备更好的可读性和可理解性。

2.2.3 管理者的概念技能

1. 概念技能是管理者统观全局、面对复杂多变的环境，具有分析、判断、抽象和概括并认清主要矛盾，抓住问题实质，形成正确概念，从而形成正确决策的能力。
2. 具有概念技能的管理者会把自己的组织看作一个统一的整体，并且熟悉各个小组之间的关系，能够正确地运用自己的各种技能来处理组织中出现的问题，将问题细化并各个击破，实现企业的目标。

2.3 逻辑三要素之判断

1. 判断有肯定或者否定之分，即有肯定判断和否定判断。
2. 判断有真假之分，一个判断要么真、要么假，不能非真非假。

2.4 逻辑三要素之推理

2.4.1 演绎推理：因为，因为，所以

1. 演绎推理旨在阐明前提和结论之间的关系，为评估演绎论证是否有效提供方法。
2. 演绎推理是一个从一般到特殊的过程。
3. 对于一个推理来说，首先要保证其在形式上是有效的。

2.4.2 归纳推理：从特殊到一般

1. 归纳推理是以一类事物中的若干个别对象的具体知识为前提，得出有关该类事物的普遍性知识的结论的过程。
2. 为了提高归纳推理的可靠程度，需要运用已有的理论知识对归纳推理的个别性前提进行分析，把握其中的因果性、必然性，这就要用到演绎推理。
3. 归纳推理依靠演绎推理来验证自己的结论。

2.4.3 溯因推理：大胆假设，小心求证

1. 溯因推理就是我先知道了答案，再去追溯原因的推理。
2. 如何进行溯因推理呢？简单来说，就是8个字：大胆假设、小心求证。

2.5 逻辑链

2.5.1 5Why思考法

1. 5Why思考法：对一个问题连续多次追问为什么，直到找出问题的根本原因。

注意：这里的5Why不是一定要问5次，而是要灵活运用延长逻辑链来找到问题的根本原因。

2.5.2 5So思考法

1. 5So思考法：对一个现象连续追问其产生的结果，以探求它对未来可能造成的深远影响

如果说5Why是在“因”的方向上进行拓展，回溯问题的根本原因，那么5So就是在“果”的链路上进行拓展，旨在洞悉事物未来的发展趋势。

2.6 逻辑谬误

2.6.1 偷换概念

1. 偷换概念：在论证中，总有一些被认为是理所当然的特定假设，但通常情况下，它们却不会被人明说出来。

当你看到一个关键词在论证中不止一次地出现时，就要注意其意义有没有发生改变，如果意思发生改变，那么要警惕偷换概念的谬误。

2.6.2 错误假设

1. 错误假设：假设你戴了一副镜片严重扭曲的眼镜，却没有意识到这个问题，那么你有理由相信一切人、事物都是你看到的那样，而事实上这并不是它们本来的面貌。

我们看待事物的方式或多或少地受到我们的认知、价值观、信念的影响，在我们进行逻辑推理时，这些“认知、价值观、信念”通常自然而然地作为“底色”参与其中，也正是基于这些错误假设的掩盖，很多谬误才很难被发现。

2.6.3 循环论证

1. 循环论证：循环论证是指一个结论会自己证明自己，只不过措辞有所改变。

2.6.4 以偏概全

1. 以偏概全：以偏概全是指依据不充分的例证得出普遍的结论。

2.6.5 滑坡谬误

1. 滑坡谬误：滑坡谬误是指不合理地使用一串因果关系。

2.7 非理性思考

1. 逻辑思维需要理性的思考，但是人类并不是纯粹理性的动物。
2. 在生活上，有时我们需要“傻”一点，没必要凡事都上纲上线、理性分析。

03 结构化思维

1. 结构化思维的定义与重要性。
   1. 结构化思维是以逻辑思维为基础，从无序到有序、从混乱到清晰的思维能力。
   2. 结构化思维可以帮助我们以一定的逻辑顺序从繁杂的信息中整理出清晰的结构，从而使写作和表达更清晰和易于理解。

3.1 结构与架构

1. 结构是系统的组织形式，决定了系统的性质。
   1. 系统的性质是由结构决定的。要素的内容是不稳定的，可能随时会被替换。
   2. 我们通常说的“结构性问题”是指那些底层的、难以改变的根本性问题。
2. 架构是“要素+结构”，核心也是结构。、
   1. 比如，组织的要素是员工，而组织架构就是规定了员工和员工之间协作关系的结构。
   2. 又比如，应用系统的要素是程序，而应用架构所要解决的就是如何处理这些程序要素之间的关系结构。

3.2 从无序到有序

1. 结构化思维是一种以逻辑为基础，从无序到有序搭建结构的思维过程。

有结构的信息更易于大脑记忆和理解。

2. 人类大脑在处理信息的时候，有如下两个特点：不能一次处理太多信息，喜欢有规律的信息。

3.3 金字塔结构

1. 金字塔结构满足大脑处理信息的特点——概念不能多、有逻辑关系。

我们更容易记住那些具有逻辑关系的东西，而遗忘那些散点的东西。

2. 结构不仅能提升可理解性，而且方便记忆。

转变的关键就在于结构，金字塔结构满足了我们大脑处理信息的两个要求。

3.4 金字塔中的逻辑

3.4.1 纵向逻辑关系

1. 纵向逻辑关系：纵向是层次关系，上一层思想是对其下一层思想的概括，下一层是对上一层的解释和支持。
   1. 结论先行(“论”)：所谓结论先行，就是要先抛结论。
   2. 以上统下(“证”)：金字塔是一种层次结构，上一层是对下一层的统领和抽象。

3.4.2 横向逻辑关系

1. 横向逻辑关系：横向是关联关系，每组中的思想必须属于同一逻辑范畴，并按照逻辑顺序组织。
   1. 归类分组(“类”)：将内容相似的思想归为一类，为进一步归纳抽象做好准备。
   2. 逻辑递进(“比”)：分组中的思想需要有逻辑递进关系，即它们必须属于同一个逻辑范畴，且满足一定的逻辑顺序。

3.5 如何搭建结构

3.5.1 自上而下

1. 自上而下地搭建金字塔结构，即问题分解，也叫作疑问回答分解。
   1. 2W1H是构建结构时最常用，也是最有用的框架之一。
   2. 我们还可以用“疑问解答”的方式自上而下地搭建结构。

3.5.2 自下而上

1. 自下而上地搭建金字塔结构，即概括总结做聚合。

3.5.3 上下结合

1. 上下结合，即同时使用自上而下和自下而上的方法。
   1. 自上而下的结构化分解可以帮助我们更清晰地整理业务逻辑、表达业务过程。
   2. 我们还需要自下而上的抽象建模，帮助我们提升代码的复用性、扩展性和业务语义表达能力。

3.6 更多结构思维框架

1. 除了前面提到的2W1H，5W2H也是解决一般问题时非常有用的思维框架。

5W2H分别代表Why、Who、When、Where、What、How和How much。

2. 针对不同的问题场景，前人已经总结了很多解决特定问题的结构框架。
   1. 制定市场营销策略的“4P”模型：即产品策略（Product Strategy）、价格策略（Price Strategy）、渠道策略（Place Strategy）、促销策略（Promotion Strategy）。
   2. 思考组织战略的“7S”模型：即经营策略（Strategy）、组织结构（Structure）、运营系统（System）、经营风格（Style）、职员（Staff）、组织技能（Skill）和共享价值观（Shared Value）。
   3. 分析竞争力的SWOT模型：SWOT分析代表分析企业优势（Strengths）、劣势（Weakness）、机会（Opportunity）和威胁（Threats）。
   4. 制定目标的SMART模型：即制定目标要满足确定性（Specific）、可度量性（Measurable）、可实现性（Attainable）、相关性（Relevant）和时效性（Time-based）。

04 批判性思维

1. 批判性思维是对思维过程的再思考，目的是形成正确的结论，并做出明智的决策和判断。

批判性思维并不是让你批评、否定或者抨击别人，而是教你如何提升分辨能力、判断力。

2. 批判性思维不仅有利于我们做出高质量的决策，更重要的是，它会培养我们保持怀疑的态度和理性思考的习惯。

就像哲学家笛卡儿说的，如果我们没有证据和理由支持某一结论，那么绝不会相信它为真。

4.1 理解批判

1. 批判性思维要经历3个过程：体验、解释和分析。
2. 批判性思维在我们文化中的缺失及其原因。
   1. 我们的文化比较讲究经验和直觉，而批判性思维比较注重理性和逻辑。
   2. 我们的文化比较讲究包容和认同，而批判性思维常常需要反驳和质疑。

4.2 批判中台

4.2.1 中台的底层逻辑

4.2.2 业务中台为何低效

1. 业务中台低效的根本原因在于，前台业务和业务中台的“深度单体耦合”。
   1. 协作成本：研发≠写代码，实际上我们大部分时间不是在写代码，而是在沟通协调。
   2. 认知成本：业务中台体系复杂，增加了开发者的认知负荷。
   3. 稳定性成本：业务中台与所有的大设计犯了同一个错误，即忽视了那些“对未知的未知”。

4.2.3 解决中台的困境

1. 解决中台的困境的方法：把业务能力做薄，把中台能力做强，把系统结构做简单。
   1. 解耦：前台业务和业务中台的关系，必须从代码和部署的耦合状态变成分布式的服务关系。

4.3 批判架构师

1. 架构师的价值和他做的决定是成反比的。

4.3.1 尴尬的架构师

4.3.2 尴尬的架构部门

4.3.3 人人都是架构师

1. 架构师所要具备的架构能力实际上就是一套分析问题、解决问题的方法论。
2. 每个工程师都应该具备一定的架构能力，人人都应该是架构师。

4.4 批判技术管理者

4.4.1 技术不作为

1. 技术不作为：现在很多的技术人员一旦晋升到TL岗位就开始脱离技术工作。

如果一个TL从来不关注技术、不写代码，对技术没有热情也不学习，甚至其本身技术就很差，那又怎么能指望在他领导下的团队能有技术味道呢？

4.4.2 业务不思考

1. 业务不思考：现在很多TL每天混迹在各种会议上，忙着做各种沟通协调的事情。

很多会议其实是低效无意义的，所以TL需要更注重独立思考，而不是人云亦云。

4.4.3 脾气超火爆

4.5 自我批判

1. 坚持自我批判是华为的核心价值观之一。
   1. 没有自我批判，我们就不会认真听清客户的需求，就不会密切关注并学习同行的优点，就会陷入以自我为中心，必将被快速多变、竞争激烈的市场环境所淘汰。
   2. 没有自我批判，我们面对一次次的生存危机，就不能深刻自我反省，自我激励，用生命的微光点燃团队的士气，照亮前进的方向。
   3. 没有自我批判，就会固步自封，不能虚心吸收外来的先进东西，就不能打破局限，把自己提升到全球化大公司的管理境界。
   4. 没有自我批判，我们就不能保持内敛务实的文化作风，就会因为取得的一些成绩而少年得志、忘乎所以，掉入前进道路上遍布的泥坑陷阱中。
   5. 没有自我批判，就不能剔除组织、流程中的无效成分，建立起一个优质的管理体系，降低运作成本。
   6. 没有自我批判，各级干部不讲真话，听不进批评意见，不学习不进步，就无法保证做出正确决策和切实执行。
2. 自我批判也是对自己的提升。

05 维度思维

5.1 维度究竟是什么

1. 维度是事物“有联系”的抽象概念的数量或者变量的数量。

5.2 多维度思考

1. 多维度思考是思考的高级阶段，是体系化思考的必备，是解决复杂问题的一把利器。

一个人能进行思考的维度越多，对一个问题的理解就会越全面、越深入。

5.3 不做if else程序员

5.3.1 多态扩展

5.3.2 代码分离

5.3.3 矩阵分析

1. 矩阵分析是解决多维问题的利器。
   1. 矩阵分析首先要找到影响问题域的核心要素，也可以叫变量、维度，然后显性化地构建矩阵。
   2. 当维度和维度属性值比较少的时候，可以用四象限、九宫格或立方体进行视觉上的呈现。

5.3.4 殊途同归

5.4 无处不在的矩阵分析

5.4.1 波士顿矩阵

波士顿矩阵：把销售增长率和市场占有率作为产品分类的核心指标。

5.4.2 订单要素分析

订单要素分析：使用矩阵将问题域清晰地呈现出来，可以让人一眼看清订单业务的全貌。

5.4.3 RFM模型

RFM模型：依托于用户最近消费时间（Recency, R）、消费频率（Frequency, F）、消费金额（Monetary, M）3个维度进行评估。

5.4.4 逻辑推理中的矩阵

逻辑推理中的矩阵：建构一个备选项的图示是非常有帮助的，这种图示叫作矩阵。

5.4.5 相关系数矩阵

相关系数矩阵：在数据分析中，经常会涉及多个维度（变量）。

5.5 设计模式中的维度思维

1. 在设计模式中，维度思维可以帮助我们更好地处理多维度变化的问题。

5.6 组织管理中的维度思维

1. 在组织管理中，维度思维可以帮助我们更有效地设置组织结构。

5.6.1 人员分工矩阵

对于技术团队来说，我们习惯于按领域划分工作范围，这样做的好处是责任到人、职责清晰。然而，领域只是一个维度，我们的工作通常是以项目的形式开展的，而项目通常是贯穿多个领域的。所以，在做团队组织规划时，我们可以从业务领域和业务项目两个维度入手。

5.6.2 人才盘点矩阵

阿里巴巴在做人才盘点时是从工作业绩、价值观两个方面去看的，所以绩效由工作业绩和价值观两部分组成。按照工作业绩和价值观的不同，我们把员工分成“明星”“野狗”“黄牛”和“白兔”。

5.6.3 需求管理矩阵

作为一线技术团队的管理者，我们要对接产品的需求，针对需求分配任务，并把控项目风险。当需求很多的时候，我们还要判断需求的价值，确定需求的优先级。实际上，业务需求和完成需求必备的要素（开发、测试、数据、算法、里程碑等）也构成了矩阵的关系。

06 分类思维

1. 分类是依据一定的标准对给定的事物划分组别。
2. 分类思维在工作和生活中有着重要的意义

设计就是分类，设计的本质就是分类。

6.1 分类是本能

1. 人类天生就有分类的本能
2. 分类是人类大脑的识别模式，是我们化繁为简的不二法宝。

在我们处理问题，特别是复杂问题的时候，分类思维扮演了极其重要的角色。

6.2 分类无处不在

1. 面对复杂问题时，我们必须对问题涉及的要素进行分类整理，建立逻辑关系。

我们平常所说的分析和综合的背后，其实就是分类能力。

2. 从古及今，人类一直在做着归类、分类的事情。
   1. 语言的产生离不开分类和抽象。
   2. 组织结构的设计是对人和职位的分类。
   3. 客户运营需要对目标人群进行分类（Customer Segmentation）。
   4. 应用架构是对模块（Module）、组件（Component）、包（Package）的分类设计。
   5. 在软件开发领域，面向对象编程（Object Oriented Programming, OOP）之所以可以取代结构化编程语言，正是因为与子程序相比，类具有分类、汇总、隐藏信息的作用。

6.3 分类的本质

6.3.1 寻找共同属性

1. 分类是指将有共性的事物放在一起，共性主要体现在对象的属性上。

属性是事物的性质与事物之间关系的统称。

2. 事物的属性可能是特有属性，也可能是共有属性。
   1. 对象的特有属性是指为一类对象所独有而其他类对象所不具有的属性。
   2. 共有属性没有区别性。
3. 本质属性是决定某个事物之所以成为该事物而区别于其他事物的属性。

本质属性的两个特点是：某事物固有的规定性、与其他事物的区别性。

6.3.2 经典分类与概念聚集分类

6.3.3 多种多样的分类角度

6.4 没有“完美”分类

1. 分类从来就不是一件简单的事情，即使是可枚举属性的经典分类，我们有时也会遇到困难。
2. 不存在所谓的“完美”分类，分类具有主观性。

6.5 软件设计中的分类

6.5.1 对象分类

1. 对象分类是软件设计的基础。
   1. 分类的目的是找到问题域中的“核心抽象”。
   2. 对于基于面向对象的软件系统来说，我们通过分类寻找具有共同结构或表现出共同行为的一组事物。

6.5.2 构建分类

1. 构建分类是为了更好地控制程序的复杂性。
   1. 类是系统中最基本的构建（Artifact）单元。
   2. 为了更好地控制程序的复杂性，我们还需要更大颗粒度的分类概念，也就是把成千上万个类进一步归类为包（Package）、组件（Component）、模块（Module）和应用（Application）。

6.5.3 领域分类

1. 领域分类是对问题域的分类。
   1. 领域边界划分属于面向对象分析（Object Oriented Analysis, OOA）的顶层设计。
   2. 对问题域的分析是设计工作的起点。

6.6 组织架构中的分类

1. 组织架构设计本质上就是一种职责分类。

6.6.1 业务型组织

6.6.2 职能型组织

6.7 互联网产业分类

1. 按照供给和履约的不同对互联网进行分类，可以更好地看清互联网。
   1. A类：供给和履约在线上，企业的核心能力体现在产品设计领域、用户理解，以及对通信、社交和内容的把握上。
   2. B1类：其核心能力主要体现在对品类、供应链，以及定价的理解上。
   3. B2类：有两个特点，一是大规模的线下团队，二是App中的定位功能。

07 分治思维

1. 分治思维是一种古老的、非常有效的思想，通过“分解+治理+合并”的过程解决问题。

分治并的过程是“分解+治理+合并”，合并的过程往往容易被忽视，但在实际应用中却很常见。

2. 大部分问题可以通过分治解决，比如设计模式中的分治、团队拆分、分布式服务拆分等。

7.1 分治设计模式

7.1.1 管道模式

1. 管道模式：通过把处理过程进行划分，把不同的处理分配在不同的阀门上，最后组合起来形成过滤纯净水的管道。

7.1.2 责任链模式

1. 责任链模式：很多对象由一个对象对其下家的引用连接起来形成一条链，请求在这个链上传递，直到链上的某一个对象决定处理此请求。

7.2 分布式系统

1. 分布式系统架构已成为大型互联网公司的标配，可以支撑“接近无限”的业务扩展诉求。

7.2.1 x轴拆分

1. x轴拆分：通过复制服务或数据库已分散事务处理负载压力。
   1. 服务器集群比较容易做到将流量分配到多台服务器上，从而应对高并发的业务场景。
   2. 解决数据库单点问题的方案有两种，一种是数据的水平复制(x轴)，另一种是数据分片(z轴)。

7.2.2 y轴拆分

1. y轴拆分：通过拆分不同的东西进行扩展，将复杂系统拆分成多个小系统。

不管是之前的面向服务的架构（Service Oriented Architecture, SOA）、面向资源的架构（Resource Oriented Architecture, ROA），还是现在的微服务，本质上都在做服务拆分的工作。

7.2.3 z轴拆分

1. z轴拆分：通过拆分类似的东西进行扩展，通过对数据进行分片，以及依据数据属性散列或取模的方式进行“竖切”。

7.2.4 xyz轴拆分对比

7.3 分治算法

1. 分治算法主要包含3个步骤：分、治、并。

“分”是递归地将原问题分解成小问题；“治”是在解决了各个小问题之后（各个击破之后）合并小问题的解，从而得到整个问题的解；“并”是按原问题的要求，将子问题的解逐层合并，构成原问题的解。

7.4 解决问题的黄金三步

1. 黄金三步是通用的解决问题的框架，即定义问题、分解问题、合并问题。
   1. 定义问题，弄清楚我们要解决的问题究竟是什么。
   2. 分解问题，把一个大问题拆解成多个子问题。
   3. 合并问题，对拆解后的子问题，我们有必要再进行一次合并归类。
2. 黄金三步和我们通常说的“定义问题、分析问题、解决问题”是一一对应的。

定义问题无须多言，问题分解（分治）是我们分析问题的常用手段，最后的合并问题才是真正解决问题，因为只有对子问题的整合才能最终解决问题。

7.5 “分治并”的应用

7.5.1 流式计算

1. 在流式计算中，终端操作起到了合并的作用。
   1. Stream流操作，首先要通过“中间操作”构建流式计算的管道数据结构，然后通过“终端操作”触发执行。
   2. 终端操作起到了合并的作用，这一步合并非常关键。正是有了合并的步骤，我们才能实现流的延迟执行、流的截断、流的并行等一系列Stream API中最重要的功能。

7.5.2 分布式数据库

1. 在分布式数据库中，中间件起到了合并的作用。
   1. 在完成了基于领域的垂直切分（竖切）和基于数据区间的水平切分（横切）之后，如何使用这些数据库呢？总不能让应用层点对点地去对接这么多库吧。因此，必须要有一个中间层，将这些分解后的数据库按照一定的逻辑组合起来，用中间层来屏蔽分解造成的复杂度。
   2. 在阿里巴巴，这个负责分布式数据访问的中间件叫作TDDL（Taobao Distributed Data Layer）。TDDL主要部署在iBATIS或其他ORM框架之下、JDBC Driver之上。整个中间件实现了JDBC规范，所以可以将TDDL当作普通数据源实例，并且注入各种ORM框架中使用。

08 简单思维

1. 简单能代替美观、合理、优雅。
2. 简单才会好用，特别是一个产品有十亿人在用的时候。

8.1 简化是逆向做功

1. 简化本质上是一个熵减活动。

所有的事物都在缓慢熵增，熵减就是逆向做功，即通过更多的努力让混乱的系统重新归于秩序。

8.1.1 压缩、隐藏与赋予

1. 对于小的东西，人们对它的期望值会比较低，如果它同时功能强大到超出人们的预期，那么自然可以带给人惊喜。
2. 隐藏复杂可以让用户管理自身的期望，因此需要通过强制性手段把复杂隐藏起来。
3. 赋予是指通过材料上的加强和其他暗示性信息来赋予产品更强的品质感，以达到压缩隐藏产品直观感受的平衡。

8.1.2 减少选择

1. 好的产品并不是要做到大而全，而是有节制。给用户太多的选择，有时还不如不给选择。
2. 我们应该给客户（客户端）提供简洁的接口，更少的选择也意味着更低的复杂度。

8.1.3 奥卡姆剃刀

奥卡姆剃刀原理，是指如无必要，勿增实体（Entities should not be multiplied unnecessarily），即“简单有效原理”。

8.2 干掉流程引擎

1. 流程引擎并不能降低复杂度，反而会添加新的复杂度。

基于数据库的配置，我在代码中看不到流程的全貌，如果要看整个执行步骤，那么必须借助数据库的配置数据，这严重影响了代码的可读性和系统的可维护性。

2. 全天下估计80%对流程引擎的使用都是得不偿失的。

不用流程引擎，代码也许会更简单、更美好。

8.3 极简状态机的实现

8.3.1 领域专用语言的分类

8.3.2 极简状态机的模型设计

1. 使用领域专用语言（DSL）实现一个极简的“无状态”状态机。

我们使用的大部分的状态机，其主要目的是代码业务语义显性化表达，不需要配置化和可视化。所以对于实现一个简单易用的状态机引擎来说，成本比较低的内部DSL的方式是一个不错的选择。

8.3.3 连贯接口设计

1. 连贯接口设计，限定方法调用的顺序。

连贯接口是实现Internal DSL的重要方式，因为这种连贯性能带来可读性和可理解性的提升，其本质不仅是提供API，更是一种领域语言、一种内部DSL。

8.3.4 无状态设计

1. 无状态设计，实现一个状态机只需要有一个实例就够了。

我们可以把状态机设计成无状态的，唯一的副作用是我们无法获取状态机的当前状态。

8.3.5 极简状态机的使用

8.4 COLA的壮士断腕

1. 去除CommandBus之后，代码的可理解性和可维护性得到了显著提升。
2. 拦截器功能，对于业务代码来说，本质上就是处理业务的切面（Aspect）问题。

关于面向切面编程（Aspect Oriented Programming, AOP），Spring已经提供了非常完善的功能，因此，拦截器这个设计也有点“鸡肋”。

8.5 复杂的产品没人用

1. 价格规则实际上比我想象的要复杂得多，导致运营人员无法理解和操作。
2. 使用奥卡姆剃刀，把5个维度的规则配置精简到2个，废除了运营的配置界面。

09 成长型思维

1. 成长型思维认为成功是学习的结果，努力是通往成功的关键。

成功个体的标志在于他们热爱学习、喜欢挑战、重视努力，并在面对苦难时坚韧不拔。

2. 成长型思维源自斯坦福大学心理学教授卡罗尔·德韦克的《终身成长：重新定义成功的思维模式》一书。

比尔·盖茨在给本书作序时写到：“我爱这本书的一个原因是，它不仅提供了理论，还阐明了方法。德韦克帮助固定型思维模式者转变为成长型思维模式者的方法表明，仅仅对成长型思维模式进行一番深入了解，你就能让自己的思想和生活彻底改变。”。

9.1 走过至暗时刻

9.2 成长型思维与固定型思维

1. 固定型思维认为个人能力是固定的，需要不断证明自己的能力与价值。

他们认为：成功是智力的证明，意味着自己比其他人更有天赋，拥有更多的特权；失败意味着缺乏个人技能或潜力，并会给自己贴标签，产生彻底的失败感和无力感。

2. 成长型思维认为个人能力是可以改变的，需要提高自己，去学习新的知识，从失败中吸取经验教训，拓展自己的才能。

他们认为：成功是学习的结果，意味着做到最好的自己，但自己仍是普通人；失败是一次机会，无法成为永久的定义；努力是通往成功的关键，无论个人的能力有多强，只有努力才能激发和拓展能力，取得最终的成就。

9.3 大脑的可塑性

1. 大脑的功能并不是一成不变的，而是拥有一定可塑性，通过合理的训练和调整，只要掌握正确的方法，持续成长是有可能的。
   1. 我们的大脑是由无数个神经元组成的，思考是通过神经元之间的相互连接和传递信号完成的。
   2. 随着思考力和能力水平的提升，我们的大脑会得到重塑，天赋、智商并不是在出生那一刻就被决定了的，而是可以通过学习、锻炼、挑战不断提升的。

9.4 培养成长型思维

1. 学会正确评价自己，不要过分相信天分。

一个人一旦相信了天分，就等于相信了自己的水平是基本不变的，就会给自己设限。

9.4.1 明确努力的意义

在固定型思维模式者的眼中，努力是有缺陷和不足的人需要做的。

9.4.2 改变归因习惯

将失败相对化，归因于偶发的因素，而不是归因于普遍化、人格化，也是培养成长型思维的重要方法。

9.4.3 摆脱精神内耗

1. DMN过分活跃是导致精神内耗的主要原因。
2. 只有专注力提升了，我们才可能减少精神内耗。

9.4.4 持续精进

精进是大乘佛法的六度之一，就是你每次必须比上一次进步一点点。

9.4.5 保持好奇心

成长需要好奇心的牵引，要学会苦中作乐。

9.4.6 守住平常心

平和的心态是我们持续成长的基础，因为人的专注力是有限的，内心平和的人可以更多地专注在学习和工作上。

9.4.7 慢也是快

当我们因太注重结果而匆忙赶路的时候，双脚触及地面的力度会减轻，行走的步调会紊乱，如此生活就会有失踏实感，进而降低生活的质量，难以接近成功。

9.4.8 掌握表扬的技巧

赞扬孩子的天赋，而不是他的努力、策略和选择，就是在用缓慢的方式扼杀他的成长型思维。

9.5 成功人士的成长型思维

1. 成功来源于成长，其中的精髓就是努力。

当你已经非常擅长某件事情的时候，你就会把它放在一边，并继续寻找那些更有挑战性的事情，因为这样你才能持续成长。

2. 成功人士或多或少具备成长型思维。

第二部分 专业思维能力

10 解耦思维

1. 解耦是软件设计的一大目标，模块之间的联系越少，耦合越小，系统就越灵活，可修改性越好。
   1. 在一个设计良好的系统中，数据库代码和用户界面应该是正交的。
   2. 团队之间的关系也一样，要尽量做到正交。
2. “高内聚，低耦合”是软件设计追求的重要目标之一，组件、模块、层次设计都应该遵循“高内聚、低耦合”的设计原则。

虽然我们在最初学编程时就知道要“高内聚，低耦合”，但是在实际工作中还是会干出很多“低内聚，高耦合”的事情。

10.1 耦合与解耦

1. 耦合是指两个事物之间联系的紧密程度，解耦就是要减少事物之间联系的紧密程度。
   1. 在软件领域，“耦合”是指两个事物之间联系的紧密程度。联系越紧密，耦合性越高；联系越少，耦合性越低。
   2. 软件只能通过被使用才能产生价值，而建立这个“被使用”的过程就是产生联系、产生耦合的过程。
2. 解耦有两种主要方式——依赖倒置解耦和中间层映射解耦。
   1. 依赖倒置是SOLID设计原则中的“D”，全称是Dependence Inversion Principle，即依赖倒置原则。
   2. 中间层映射的设计理念是“计算机中的任何问题，都可以通过加一层来解决”。

10.2 依赖倒置解耦

1. 依赖倒置实际上倒置的是依赖方向，反转依赖的方向，从依赖具体到依赖抽象。

有两个模块A和B，本来A是直接依赖B的，依赖方向是A→B，通过增加一个抽象C，然后让模块B去实现这个抽象，从而反转了依赖的方向，变成B→A，这就是依赖倒置。

10.2.1 抽象比具体灵活

10.2.2 面向接口编程

10.2.3 应用与日志框架的解耦

10.3 中间层映射解耦

1. 中间层映射的设计理念是“计算机中的任何问题，都可以通过加一层来解决”。

10.3.1 DNS的解耦设计

在DNS的设计中，中间层映射表现为Naming解析动态绑定。

10.3.2 CDN的解耦设计

对于内容分发网络（Content Delivery Network, CDN）的实现机制，我们可以将其理解为在DNS这个中间层上再加一个中间层CNAME。

10.4 解耦的技术演化

1. 应用技术的演化史也是一部解耦史。

从面向对象的“原始社会”到面向资源的“云淡风轻”，技术的每一步发展都伴有解耦的烙印。

10.5 应用架构中的解耦

1. 应用架构之道，就是要实现业务逻辑和技术细节的解耦。

不管是六边形架构、洋葱圈架构，还是COLA架构，其核心要义都是做核心业务逻辑和技术细节的分离和解耦。

2. 通过依赖倒置方式，我们倒置了领域层和基础设施层的依赖关系，让两个模块从原来的依赖关系变成了正交关系。
   1. 假如某个应用中需要用到类目（Category）这个实体，但是类目又不在本域中，需要通过一个RPC调用才能获取相应的信息。那么这时我们就可以在领域层中定义一个类目网关（CategoryGateway），这是一个纯抽象的概念。
   2. 在基础设施层中，类目网关是如何被实现的呢？典型的实现代码如下所示，首先需要实现类目网关中定义的获取类目信息的方法，在该方法中，我们通过RPC或数据库获取类目数据对象“CategoryDO”，然后将这个数据对象“翻译”成我们想要的类目实体“Category”。

11 契约思维

1. 契约精神是社会协作的前提，也是软件工程师协作的前提。
2. 契约思维在软件工程中有规范和标准两个方面的重要价值。
   1. 规范价值：一致性可以降低认知成本和复杂度。
   2. 标准价值：大规模社会分工协作离不开标准。

11.1 软件设计中的规范

11.1.1 命名规范

1. 命名规范：确保命名的一致性。

对于核心的领域概念，应该有一个核心领域词汇表。

11.1.2 异常处理规范

1. 异常处理规范：统一异常处理，简化异常处理逻辑。
   1. 对于异常，建议最好采用fail fast（快速失败）的策略。
   2. 对于服务调用者，需要制定一个服务重试、服务降级的策略。

11.1.3 架构规范

1. 架构规范：通过架构约束解决系统中的一部分混乱问题。

11.1.4 规范的维护

1. 规范的维护：保证架构规范、代码规范不被破坏。
   1. 需要团队负责人和团队成员有贯彻执行的决心和能力。
   2. 考虑使用代码扫描工具，尝试把一些不规范的行为进行量化。
   3. 尽量多地做代码审查(Code Review)。

11.2 软件设计中的标准

11.2.1 前端标准化之路

1. 前端标准化之路：W3C的标准集合涵盖了网页的3个组成部分：结构（Structure）、表现（Presentation）、行为（Behavior）。
   1. 结构化标准主要包括XHTML和XML。
   2. 表现标准语言主要包括CSS。
   3. 行为标准主要包括（如W3C DOM）、ECMAScript等。

11.2.2 Java规范

1. Java规范：JCP是一个开放的国际组织，维护的规范包括J2ME、J2SE、J2EE、XML、OSS、JAIN等。

11.2.3 API设计标准

1. API设计标准：良好的API设计要至少遵循3个标准，分别是可理解性、封装性和可扩展性。
   1. 可理解性：不管是设计API，还是编写业务代码，可理解性都是我们的首要目标。
   2. 封装性：API应该是对实现细节的封装。
   3. 可扩展性：API作为一个重要契约，一旦发布出去，想要修改就会变得比较困难。

11.3 依赖契约的扩展机制

11.3.1 基于接口的扩展

1. 基于接口的扩展：主要利用面向对象的多态机制。

11.3.2 基于配置数据的扩展

1. 基于配置数据的扩展：首先要约定一个数据格式，然后利用用户提供的数据组装成实例对象。

11.4 掌握标准制定权

1. “一流的企业定标准，二流的企业做品牌，三流的企业卖产品”，谁掌握了标准制定权，谁就是王者。
   1. 在分布式的微服务环境下，通过多个微服务的相互协作对外提供完整的业务功能，API的提供者拥有标准的制定权。
   2. SPI的意思是，我需要这样的服务，而且我已经把标准（Interface）定义好了，你按照这样的方式给我提供服务就好了。
   3. 无论是JDBC标准，还是SLF4J标准，虽然标准制定方不需要提供具体实现，但这并不妨碍它是更权威、更有影响力的一方。

12 模型思维

12.1 模型及其分类

1. 模型是对现实的简化抽象，可以表达不同概念的性质。
   1. 如果一件事物能随着另一件事物的改变而改变，那么此事物就是另一件事物的模型。
   2. 一个概念可以使很多模型发生不同程度的改变，但只要很少的模型就能表达出一个概念的性质。
2. 模型可以分为物理模型、数学模型、概念模型和思维模型等。
   1. 物理模型是指拥有体积及质量的物理形态概念实体物件。
   2. 数学模型是用数学语言描述的一类模型，可以是一个或一组代数方程、微分方程、差分方程、积分方程或统计学方程。
   3. 概念模型是对真实世界中问题域内的事物的描述，是领域实体，不是对软件设计的描述。
   4. 思维模型其实是现实世界复杂系统的某个侧面或某个局部的规律，或者近似规律现象的表征工具。

12.1.1 物理模型

12.1.2 数学模型

12.1.3 概念模型

12.1.4 思维模型

12.1.5 模型不能代替实物

12.2 UML建模工具

1. UML是在软件工程中具有广泛共识的建模方法、语言和表示法。
   1. UML的目标之一是为开发团队提供标准通用的设计语言来开发和构建计算机应用。
   2. UML提出了一套IT专业人员期待多年的统一的标准建模符号。
2. UML建模语言分为结构型和行为型两种。
   1. 结构型建模语言用于描述系统的静态结构，包括类图、对象图、包图、组件图和部署图。
   2. 行为型建模语言用于描述系统的动态行为，包括用例图、序列图、协作图、状态图和活动图。

12.2.1 类的UML表示法

12.2.2 类的关联关系

12.2.3 类的依赖关系

12.2.4 类的泛化关系

12.2.5 类与接口的实现关系

12.3 领域模型

1. 领域模型是对领域内的概念类或现实世界中对象的可视化表示。
   1. 领域模型专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。
   2. 领域模型将现实世界抽象为了信息世界，把现实世界中的客观对象抽象为某一种信息结构，而这种信息结构并不依赖于具体的计算机系统。
2. 领域模型对软件开发至关重要，是连接问题和解决方案的桥梁。

从本质上来说，软件开发就是从问题空间到解决方案空间的映射转化，而领域模型是连接问题和解决方案的桥梁。

12.3.1 限界上下文

12.3.2 上下文映射

12.4 领域模型与数据模型

1. 领域模型关注的是领域知识，数据模型关注的是数据存储。
   1. 领域模型是业务领域的核心实体，体现了问题域中的关键概念，以及概念之间的联系。
   2. 数据模型关注的是数据存储，所有的业务都离不开数据，以及对数据的CRUD。
2. 领域模型和数据模型有明显的区别，领域模型关心的是业务概念，数据模型关心的是数据存储。
   1. 领域模型是面向领域对象的，要尽量具体，尽量语义明确，显性化地表达业务语义是其首要任务，扩展性是其次。
   2. 数据模型是面向数据存储的，要尽量可扩展。

12.4.1 错把领域模型当数据模型

12.4.2 错把数据模型当领域模型

12.4.3 两种模型各司其职

13 工具化思维

1. “懒”是比低效的勤奋更智慧、更难得的美德。

“懒”分为3个境界：实在懒、开明懒、智慧懒。

2. 智慧懒是使用工具完成不喜欢的任务，以便再也不用做无谓的重复工作。

我们通过工具提效，从而节省大量的工作时间，而不是靠蛮力一遍一遍地重复手工劳动。

13.1 你我都是“工具人”

1. 软件工程师和其他工程师的重要区别之一在于需要自己制造工具。
2. 工具化的最佳时间点不是工作的一开始，而是当一个事情手动重复3次以上时。

如果这个工作重复3次以上，就说明这是一个需要经常处理的问题，值得投入精力和时间去做工具化。

13.2 工具化的一般步骤

1. 重复3次：当一个工作需要手动重复3次以上的时候，我们就要停下来考虑一下是否需要工具化了。

对于临时性、一次性的工作，没必要花更多时间去造工具，因为投资回报率（Return On Investment, ROI）不高。

2. “现状”和“期望”二者之间的差距：工具的目的是解决问题，所以把问题定义清楚很关键。
3. 1个工具：针对要解决的问题给出的解决方案。

13.3 TestsContainer小工具

13.4 组合创新也是创新

1. 对现有工具的组合也是一种工具化思维。

13.5 ORM工具

1. 简单直接的MyBatis反而是更好的选择，它只尝试做好一件事——从数据库表到数据对象（Data Object, DO）的一一映射。
2. 我们可以设计一个通用的Mapper（映射器），从而避免重复写这些价值不大的CRUD代码。

13.6 基础设施即代码

1. 基础设施即代码（Infrastructure as Code, IaC）这个概念是Martin Fowler于2014年提出来的。
2. 像管理代码一样管理基础设施，可以带来很多好处。
   1. 在可靠度方面，比起指挥普通人去执行文档，执行代码更精确。
   2. 在资源管理器中保存所有代码，这样每个配置参数和每次变化都可以被记录下来用于审计，有助于我们回溯和诊断问题。
   3. 基础设施是不可变的，任何人都不能登录服务器做即时调整。任何线上的小修改都有风险，所以我们每次开发代码都必须当作开发持久的定义代码来对待。这说明如果用代码来实现更新，操作会更快。

13.7 巧用便签贴

14 量化思维

1. 没有量化，就无法优化。

“科学管理之父”温斯洛·泰勒的观点。

2. 量化思维的意义不仅在个人生活上，工作中也需要量化思维。

14.1 量化的步骤

14.1.1 定义指标

1. 定义指标：找到那个可以用来量化问题的关键指标。
   1. 指标就是方向，弄错指标就会走偏。

14.1.2 将指标数字化

1. 将指标数字化：围绕关键指标，明确需要哪些数据来实现指标的计算。

14.1.3 优化指标

1. 优化指标：有了数据指标之后，要围绕指标数据迭代优化，达成业务目标。

定义指标和数字化建设虽然很关键，但优化指标才能真正为企业创造商业价值。

14.2 研发效能度量

14.2.1 度量不是“指标游戏”

1. 度量不是“指标游戏”，要找准度量在技术团队中的位置。
   1. 度量本身并没有错，关键要找准度量在技术团队中的位置。
   2. 度量的设计目标是能够引导出正确的行为。度量是为目的服务的，所以好的度量设计一定对目的有正向牵引的作用。

14.2.2 力求合理的度量

1. 力求合理的度量，避免适得其反。

14.3 目标管理

14.3.1 SMART原则

1. SMART原则：制定工作目标时必须谨记的5项要点。
   1. Specific（明确性）：指要用具体的语言清楚地说明你要做什么。
   2. Measurable（可衡量性）：指完成目标后，你可以根据当初设定目标时所设定的条件来衡量目标完成的效果。
   3. Achievable（可行性）：指你所设定的目标要在你的能力范围内。
   4. Relevant（关联性）：指你的目标最好和你要拿到的结果是有关系或有帮助的。
   5. Time-Bound（时限性）：指一定要给自已的目标设定一个时间限制。

14.3.2 OKR考核指标

1. OKR考核指标：更注重短期利益和长期战略之间的平衡。
   1. OKR可以不和绩效挂钩，主要强调沟通和方向。
   2. OKR比KPI多了一个层级的概念，O（Objective）是要有野心的，有一定的模糊性，但是KR（Key Results）是可量化的，并且KR一定要为O服务，不能偏离O的方向。

14.3.3 不要迷信指标

1. 不要迷信指标：指标和目标常常并不是充分且必要的关系。
   1. 指标是为了实现目标的，但是在实践过程中，指标却经常是与目标为敌的。
   2. 管理者常常把目标拆解为指标，时间久了，他就只记得指标，而忘了其背后更重要的目标。

14.4 量化网站运营

1. 具备量化意识，知道如何看清问题并用数字去定义问题。
2. 前端埋点技术是对量化思维非常好的实践。
   1. 对于产品经理来说，要清楚用户在使用产品时做的第一件事情是什么，接着还会做什么，他的轨迹和动线是怎样的。
   2. 对于运营人员来说，要清楚一次活动带来了多少访问量、转化率如何、通过不同渠道过来的用户表现怎么样、最终转化成活跃用户的又有多少。
3. 淘宝联盟有和外部网站进行合作的广告项目，通过SPM模型跟踪合作效果。
   1. SPM模型可以跟踪一个宝贝详情页引导成交的效果数据。
   2. 通过SPM模型，淘宝可以跟踪所有外部合作站点的合作效果。

14.5 量化技术贡献

1. 认识到量化带来的挑战，并尽最大努力将“不可量化的”变成“可量化的”。

这种努力的关键之处在于两点，一是能否进行数字化，二是数字化之后能否收集到数据。

2. 在业务项目之外找到一个属于技术人自己的量化指标。

15 数据思维

1. 数据是公司的重要资产，工程师必须了解公司的数据体系。
2. 数据化思维是运营、产品、技术人员必备的能力之一。

对于技术人员，特别是业务部门的技术人员来说，数据能力已经不是可有可无的加分项，而是必备的能力之一。

15.1 “精通”数据

1. 了解公司的数据技术体系，对大数据处理框架、数据仓库、数据分析等有基本的认知。

有了认知之后，我们就能更好地与数据工程师、数据分析师、商业智能分析师等人员进行分工协作。

2. 知道用数据去说话，学会用数据作为决策的依据。

在与业务方讨论业务需求或与产品经理讨论产品设计的时候，就可以使用数据去佐证我们的判断。

15.2 数据体系概览

15.2.1 数据源

数据源通常是工程师最熟悉的部分，这些数据一般存储在数据库，比如关系数据库、NoSQL中。

15.2.2 数据仓库

数据库专注于OLTP，而数据仓库专注于联机分析处理（OLAP）。

15.2.3 ETL

ETL，是Extract-Transform-Load的缩写，用来描述将数据从来源端经过数据抽取（Extract）、数据转换（Transform）、数据加载（Load）至目的端的过程。

15.2.4 元数据

元数据（Metadata）是关于数据的数据。

15.2.5 数据应用

15.3 数仓建模

1. 数据模型就是组织和存储数据的方式，强调从业务、数据存取和实用的角度合理地存储数据。

有了适合业务和基础数据存储环境的模型，那么大数据就能在性能、成本、效率和质量之间取得最佳平衡。

15.3.1 维度模型

1. 维度模型是数据仓库领域的权威专家Ralph Kimball所倡导的。
   1. 在维度建模中，将度量称为“事实”，将环境描述为“维度”。
   2. 维度的设计过程就是确定维度属性的过程，如何生成维度属性，以及所生成的维度属性的优劣，决定了维度使用的便捷与否。

15.3.2 事实明细表

1. 事实明细表要紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程。

与维度表相比，事实明细表通常要细长得多，行的增加速度也比维度表快很多。

15.3.3 事实汇总表

1. 事实汇总表主要通过汇总DWD来获得改进查询性能的效果。

通过访问聚集数据，可以减少数据库在响应查询时必须执行的工作量，从而快速响应用户的查询，同时有利于减少不同用户访问明细数据带来的结果和口径不一致问题。

15.4 数据产品平台

1. 阿里巴巴主要以“生意参谋”作为官方统一的数据产品平台。
   1. 生意参谋诞生于2011年，早期只应用于阿里巴巴B2B市场的数据产品，2013年10月才正式进入淘系。
   2. 从2014年起，阿里巴巴开始OneData体系的建设，并在2015年年底将其升级为官方统一的商家数据产品平台。
2. 生意参谋的数据来自阿里巴巴大数据公共层OneData。

OneData可以对集团内外数量繁多的数据进行规范化和数据建模，从根本上避免了数据指标定义不一致、重复建设的问题，从而确保生意参谋对外数据口径标准统一，计算全面、精确。

3. **生意参谋共有7个板块，除首页外，还有事实直播、经营分析、市场行情、自助取数、专题工具、数据学院。**不同板块的数据不尽相同，但又彼此联系。从商家的实际应用场景来看，这些数据服务可以划分为3个维度，即看我情、看行情和看敌情。

15.4.1 看我情

15.4.2 看行情

15.4.3 看敌情

15.5 用数据说话

1. 在工作中，技术人员被要求具有思辨的执行力。

这是为了发挥员工的主观能动性，从被动执行变为主动思考。

2. 对于有争议的问题，如果有数据作为佐证，情况就会大不一样。

16 产品思维

1. 产品思维是站在用户的视角去解决用户的问题。

产品就是用来解决某个问题的东西。

2. 产品经理并不是一个专业，人人都是产品经理。

在这个“鱼龙混杂”的队伍中，牛人很多，“传话筒”也很多。

3. 技术人员需要具备一定的产品思维，才能辨别产品需求的真伪。

16.1 产品的三要素

16.1.1 用户

1. 用户是产品要服务的对象，即使用产品的人。

客户（Customer）和终端用户（End User）可能不是一个人。

16.1.2 需求

1. 需求即产品要解决的核心问题是什么。

需求是分层次的，最浅一层是需求的表象；第二层是观点和背后的目的；最深一层是人性。

16.1.3 场景

1. 场景即用户何时何地需要使用产品。

16.2 产品的分类

16.2.1 用户关系角度

1. 从产品与用户关系的角度，可以把产品分为3类：单点、单边、多边。
   1. 单边用户型产品需要一群人同时使用，只有一个人有电话是没有意义的，使用这个产品的用户越多，价值越大，产品也就有了网络效应。
   2. 多边用户型产品一般是平台级产品，需要几群不同的人一起使用才能产生价值。

16.2.2 用户需求角度

1. 从用户需求角度，可以把产品分为6类：工具、内容、社交、交易、平台、游戏。
   1. 工具：解决单点问题。
   2. 内容：价值观过滤器。
   3. 社交：彼此相互吸引。
   4. 交易：做生意卖东西。
   5. 平台：复杂的综合体。
   6. 游戏：打造平行世界。

16.2.3 用户类型角度

1. 产品的用户多种多样，但我们最常听到是2B和2C这两类。

2B（to Business）即面向政府部门、2D（to Developer）即面向开发者，其实它们也都可以归类到2B或2C中。

16.2.4 产品形态角度

1. 在互联网和IT行业中，常见的产品形态有手机App、网站、智能硬件等。

按照技术实现的不同，可以分为两种形式：BS结构和CS结构。

16.3 产品架构

16.4 产品化

1. 产品化是指把一种技术、一种服务通过标准化、规范化的流程形成可大规模复制生产和发布的能力。

它主要体现的是一种能力的复用性和可移植性。

2. 产品化诉求的核心要点是将一种技术能力或一种服务能力与个体（独立的人）分开，形成不依托于个体存在的能力。

16.5 平台化

1. 平台也是一种产品，即平台型产品。
   1. 在商业的语境下，平台是指进行某项工作所需要的环境或条件。
   2. 在产品的语境下，平台是指能容纳多角色共建的“生态”系统。
   3. 在技术的语境下，平台是指可复用的硬件或软件的操作环境，其目的只有节约成本及提升软件研发效率。

16.5.1 企业平台化

1. 企业平台化是指抽取公共模块，解决技术复用问题。
   1. 对于稍具规模的互联网企业来说，其整体技术架构在宏观上会呈现出烟囱的形式。
   2. 建设统一的技术平台（中间件和大数据处理）有利于企业技术栈的统一，减少重复造轮子，可以有效地提升企业整体的研发效率。

16.5.2 平台化建设

1. 平台化建设关键在于抽象和复用。

对软件功能模块进行抽象复用是极具挑战性的工作，如果分析不当或经验不足，就有可能做出错误的抽象方案。

2. 用产品思维去建设平台，我们可以从价值的角度出发，更多地关注用户体验。

平台作为一个产品，除产品形式（可能就是API）和用户（内部前台团队）外，在其他方面与其他产品没有什么不同。这意味着在产品构建上，我们过去已经积累的大量成熟的方法和工具都可以平移应用到平台的建设上来。

16.5.3 平台产品化

第三部分 思维能力的综合应用

17 我的商品团队之旅

17.1 落地新团队

17.1.1 熟悉人

17.1.2 熟悉业务

17.1.3 熟悉技术

17.1.4 熟悉文化

17.2 深入商品领域

17.2.1 领域概念

17.2.2 概念模型

17.2.3 产品架构

17.3 商品上架重构

17.3.1 复杂的商品上架流程

17.3.2 无用的流程引擎

17.3.3 问题的本质在于结构

17.3.4 结构化分解后的问题

17.4 复杂业务应对之道

17.4.1 上下结合

17.4.2 能力下沉

18 COLA的演进过程

18.1 COLA 1.0

18.1.1 复杂度来自哪里

18.1.2 COLA 1.0的设计

18.1.3 COLA 1.0的整体架构

18.2 COLA 2.0

18.2.1 新架构分层

18.2.2 新组件划分

18.2.3 新扩展点设计

18.2.4 新二方库定位

18.3 COLA 3.0

18.3.1 去掉Command

18.3.2 去掉Interceptor

18.3.3 去掉Validator等

18.3.4 优化类扫描

18.3.5 用Adatper代替Controller

18.4 COLA 4.0

18.4.1 架构的顶层设计

18.4.2 技术维度与领域维度的划分

18.4.3 COLA组件

18.4.4 COLA 4.0的改动点

18.5 如何使用COLA