• 幸存者偏差：高估了成功的概率
• 看清楚自己
• 是否高估自己
• 是否陷入从众心理
• 是否与沉没成本难舍难分
• 是否是互惠互利陷阱
• 摆脱确认偏差，不要证明自己是正确的
• 是否屈服于权威
• 是否依据对比来判断（请不要怎么做）
• 现成偏见
• 是否故意营造一种危机气氛
• 明确判断他人的能力范围
• 警惕控制错觉
• 警惕激励过敏
• 是否是平均值会起作用？
• 警惕公地悲剧
• 切勿只以结果判断决定
• 面对选择，遵守自己的标准
• 排除对他人好感的影响
• 禀赋效应 let it go
• 无巧不成书，如果从不发生才令人感到意外
• 唱反调的人也许是最重要的人
• 0风险偏误
• 稀有性谬论
• 概率偏误-前车之鉴后事之师
• 独立事件-赌徒谬论
• 锚定效应，你的锚在哪里？
• 警惕归纳法，警惕黑天鹅事件
• 厌恶风险，但不要无视损失
• 社会性懈怠
• 赢家诅咒-你会得到什么、失去什么
• 是否高估了人的影响
• 相互关系不等同于因果关系
• 避免光环效应过度影响总体印象
• 合理不一定真实
• 不要被框架效应限制注意力
• 遇到不明情况，就会发生行动偏误
• 不作为偏误，如果不解决问题，你就是问题的一部分
• 自利偏误，为什么你从来不自责
• 避免长时间负面影响
• 自我选择偏误
• 联想偏误，不要欠拟合也不要过拟合
• 认知失调，是否在自我安慰
• 即使行乐，只限周末，不要为了眼前的利益破坏未来的利益

本人本身不太喜欢方法论，感觉都是套路，生搬硬套不适合自己，敏捷开发就是其中让我保持谨慎态度的方法论之一。

敏捷开发与Scrum

对于一个项目来说，能够即快又好地完成当然是非常棒的，但是众所周知，受限于项目管理三要素：时间、质量、成本，只能折衷选择。因此「敏捷」作为一种方法论（虽然Agile自称为Culture）被提出，其中Scrum(/skrʌm/，一种球类比赛)是比较知名的实现类之一。

在Scum中，它主要强调将瀑布式开发流程转为多阶段小迭代，可以理解为CPU的多级流水线(Instruction pipeline)设计，流水线设计将CPU的计算逻辑拆分，实现了复用计算模块，进而提高了时钟频率，同时也引入了寄存器/分支预测等管理模块增加了复杂度。

类似于CPU流水线机制，敏捷开发本质是在保持时间、质量不变的情况下，通过投入管理成本降低开发过程的空转成本，进而提高时钟周期的方法。

用白话来说，可以把软件开放比作流水车间，把PM，SE比作流水线工人。

我见过的的假敏捷

然而到了现实，由于各种原因，却很容易成为假敏捷

• 将工位的隔栏拆开变成网吧“敏捷岛”
• 强行将Release计划拆成一个月一版，将Sprint拆成2周就看作快速迭代，照着人月神话反着搞
• 招聘一堆无责任心的开发让你去“敏捷”，永远无法实现“全功能部队”
• 客户难沟通，PO低估工作量，SE设计缺陷，编码质量低等原因，最终导致延期
  上述任何一个问题，都可能导致最终项目一锅粥，导致高层焦虑，中层跑路，底层混日子的结果。

敏捷能够提供强大高效的方法论，但是前提是需要本身基础过硬的团队，敏捷只能帮助存在进步瓶颈的团队。如果项目已经空心化，债务多，这不是敏捷方法论应该解决的问题。

职业发展的驱动力应该来自自身，工作属于公司，职业生涯属于自己。

第一要务 拥有正确的心态

大多数人形成的错误的心态: 认为在为公司打工，没有把自己的职业生涯当作生意来看待。铭记在心，开始积极主动的管理自己的职业生涯吧。

像企业一样思考

自己能提供什么:自己的能力就是创造软件
自己需要做什么:

• 持续不断地改进和完善自己的产品

• 传达自己的价值，和千万同行的独特之处

一头扎进工作不可能非同凡响，你应该：

• 专注于你正在提供怎样的服务， 以及如何营销这项服务；
• 想方设 提升你的服务；
• 思考你可以专注为哪一 特定类型的客户或行业提供特定的服务；
• 集中精力成为一位专家，专门为某一特定类型的客户提供专业的整体服务（ 记住， 作为一个软件开发 人员， 你 只有真正专注 于一类客户，才能找到非常好的工作）。
• 更好的宣传自己的产品，更好的找到你的客户

第二要务 设定自己的目标

无论因为何种原因你没有为自己的职业生涯设定目标， 现在都是时候设定目标了。 不是明天， 也不是下周， 就是现在。 没有明确的方向， 你走的每一步都是徒劳的。

如何设定目标？

先在心中树立一个大目标，然后分解成多个小目标

追踪你的目标

定期核对自己的目标，必要时还要调整。

人际交往能力

SLA

在构建大型系统时，常常会遇到各种错误。在计划构建一个系统时，定义系统的“健康状态”十分重要。

“健康状态”必须是可度量的，一般做法是使用SLAs来度量系统的“健康状态”。最常见的SLA为

• 可达性

  从时间维度衡量（99.999%可达性，每年下线50分钟）

• 准确性

  对于数据的丢失或失真是否可以接受？可以达到多少百分比？对于支付系统来说，不接受任何数据的丢失和失真

• 容量

  系统支持并发

• 延迟

  响应延迟，一般衡量95%请求的响应时间和99%请求响应时间

确保新系统比被替代系统“更好”，可以使用上面四个SLA指标来衡量，可达性是最重要的需求。

水平和垂直伸缩

随着新业务的增长，负载也会增加。最常见的伸缩策略是垂直和水平伸缩。

水平伸缩就是增加更多的机器或节点，对于分布式系统来说水平伸缩是最常有的方式。

垂直伸缩基本上就是买更大/好的机器。

一致性

可达性对于任何系统都是很重要的，但是分布式系统一般都构建在低可达性的机器上（比如：服务的可达性要求99.999% 机器的可达性为99.9%）。简单的做法是维护一组机器组成集群，这样服务的可达性不依赖单独的机器。

一致性是在高可用系统中最需要关心的。一个一致性系统在所有的节点上看到和返回的数据在同一时间是相同的。如果使用一组机器来组成集群，它们还需要互相发送消息来保持同步，但是发送消息可能失败，这样一些节点就会因为不一致而不可达。

一致性有多个模型，在分布式系统最常用的是强一致性，弱一致性和最终一致性。一般来说，一致性要求越低，系统可以工作的更快，但是返回的数据不一定是最新的。

系统中的数据需要是一致的，但是到底是怎样的一致？对于一些系统，需要强一致性，比如一次支付必须是强一致的存储下来。对于没那么重要的部分，最终一致性是可以考虑的权衡。比如列出最近的交易。

数据持久性

持久性表示一旦数据成功添加到数据存储，它就永远可以访问到。不同的分布式数据库拥有不同级别的数据持久性。一般使用副本来增加数据持久性。

对于支付系统来说，数据不允许丢失。我们构建的分布式数据存储需要支持集群级别的数据持久型。目前Cassandra, MongoDB, HDFS和Dynamodb 都支持多种级别的数据持久性。

消息保持与持久性

分布式系统中的节点执行计算，存储数据，互相发送消息。发送消息的关键是消息的可靠到达。对于关键系统，经常需要消息零丢失。

对于分布式系统，发送消息一般石油分布式消息服务发送，如RabbitMQ，Kafka。这些消息服务支持不同级别的消息投递可靠性。

消息保持表示当节点处理消息失败时，在错误被解决前消息一直被保持着。消息的持久性一般在消息队列层被使用。如果在消息发送的时候队列或节点下线了，那在它们重新上线是还能接收到消息。

在支付系统中我们需要每一条消息投递一次，在构建系统中保证投递一次和投递至少一次在实现上是有区别的。最后我们使用了kafka来保证投递至少一次。

幂等性

在分布式系统中，很多东西都可能出错，连接会丢包或超时，客户端经常会重试这些请求。一个幂等的系统保证无论多少特定的请求被执行，一个请求实际的操作只会执行一次。比如支付请求，如果客户端请求支付并且请求已经成功，但是客户端超时了，客户端是能够重试相同的请求的。对于一个幂等的系统，一个个人的支付是不能被收取两次的。

对幂等的设计，分布式系统需要某种分布式锁机制。假设我们想要使用乐观锁来实现幂等性，这时系统需要强一致性的锁来执行操作，我们可以使用同一个版本的乐观锁来检查是否有启动了额外的操作。

根据系统的一致性和操作的类型，有很多方式来实现幂等性。在设计分布式系统时，幂等性时最容易忽略的。在支付系统中，幂等操作时最重要的，它避免了双花和双收问题。消息系统已经保证了消息至少消费一次，我们只需要保证所有重复的消息保证幂等性即可。我们选择使用乐观锁，并使用强一致性存储作为乐观锁的数据源。

分片和法定人数

分布式系统经常需要存储大量的数据，远超一台节点的容量。一般的解决方案时使用分片，数据使用某种hash算法被水平分区。尽管很多分布式数据库屏蔽了分片的实现，但是分片还是挺有意思的，特别是关于重新分片。

许多分布式系统在多个拥有数据和统计信息。为保证对数据操作的一致性，使用基于投票的方式是不行的，只有超过一定数量的节点操作成功，这个操作才是成功的，这个叫做法定人数。

Actor模型

描述分布式系统最普遍的做法是使用Actor模型，还有一种方法是CSP。

Actor模型基于actor互相发送消息并作出回应。每一个actor只能做少量的动作，创建其他actors, 发送消息或者决定如何处理下个消息。通过这些简单的规则，复杂的分布式系统可以被准确描述，可以在actor崩溃后自我修复。

使用akka提供了标准的分布式模型，避免我们重复造轮子。

反应式架构

当构建大型分布式系统时，目标常常是它们的弹性，伸缩性，和扩展性。反应式架构是在这个领域最流行和最通用的方案。

1.1 一个简单的例子

一个计算顾客租赁影片费用的程序，能容易写成面条式的代码（流水账）：顾客类调用影片类和租赁时长计算费用

对机器来言只要能运行正确没有好代码和坏代码之分，但是对（维护的）人来说很难找到修改点，容易引入bug

1.2重构前先写测试保证重构结果

利用单元测试保证重构正确性

1.3以微小的步伐修改程序，保证问题快速发现解决

不要为修改变量名感到羞耻，只有写出人能理解的代码才是好程序员

重构完可能 性能变差，但同时会带来更多的机会来优化

1.4干货－用多态代替switch

switch需要关心具体条件，多态具有switch不具备的优势：不需要关心具体类型

2.1重构的定义

重构：不改变运行结果下 提高理解性 降低修改成本

2.2重构的原因

• 代码结构的流失是累积性的，越难看懂代码设计意图，越难保护其设计

• 消除重复代码，方便修改

• 我们编写代码时很容易忘记读者的感受，造成他人时间的浪费

• 重构时犯错可以加深对代码意图的理解，可以帮助发现bug

• 好的结构设计是加速开发的根本

2.3重构的时机

• 添加功能时重构，在修改过程中把结构理清，也可以更简单的添加功能

• 修复错误时重构

• 复审代码时重构

2.4 重构的价值

程序有两面价值，今天可以为你做什么和明天可以为你做什么为了满足明天的需要，你会遇到：

• 难以阅读，逻辑重复
• 添加新功能许修改以前代码
• 复杂的条件逻辑等代码

而你希望看到的是：

• 容易阅读，所有逻辑在唯一指定地点，
• 新的修改不会危及现有行为
• 尽可能简单表达逻辑条件

重构就是把程序转变为这些特征的工具

2.5如何告诉（对付）经理

很多经理都是进度驱动，所以更加需要重构带来的好处，所以不要告诉他们 他们不会理解的

2.5.1引入间接层与重构的关系

间接层优点：

• 允许逻辑共享

• 增加解释意图和实现的机会－多了类名和函数名

• 隔离变化

• 多态封装条件逻辑

2.5.2何时不应该重构

• 软件根本不工作
• 最后期限已近

未完成的重构可以称之为债务，迟早要还

2.5.3重构与预先设计的关系

重构可以节约不必要的时间精力花在预先设计上，让软件设计向简化发展

3代码的坏味道

• 重复代码

• 过长函数

• 过大类，过长参数

• 修改一处程序的原因过多/一个原因修改过多的程序

• 数据依赖过多

• 重复的字段和参数

• 总是放在一起的字段

• switch语句

• 平行继承关系

• 不是所有分支下都需要的临时变量

• 过度耦合调用链

• 不必要的委托

• 失血数据类

• 频繁重写父类方法

• 过多注释

4~12具体如何做

自己看书吧

经济金融类：

《斯坦福极简经济学》分微观和宏观经济学 没有教科书式的介绍 比较好读，推荐

《随机漫步的傻瓜》 经验之谈 观点可以接受

《买晾衣杆的小贩为何不会倒》 贴近生活 过于简单 不推荐

《富爸爸 穷爸爸》小白入门首选 推荐

《小岛经济学》 深入浅出 最后映射中国和美国关系 后面有点看不懂 推荐

小说类：

《解忧杂货店》 个人感觉一般 后半部分剧情我都猜到了

《人间失格》 遭受到了社会的毒打 很现实 有点致郁 心里承受能力低的不推荐

《三体》 第一部可以的，后面一部不如一部 但是比起其他网上大众喜欢的爽文好多了

技术类：

《java编程的逻辑》 温故而知新，基础好的不用看了 小白推荐

《kafka权威指南》正在看 但是真的写的不错 推荐

《mybatis从入门到精通》 一般般，只有入门吧

《netty权威指南》 一般般

《redis设计与实现》 真设计与实现 推荐

《深入理解java虚拟机》多读几遍也不为过 推荐

《SpringBoot实战》 读的比较早没影响了 不推荐

《算法图解》 程序=数据结构+算法 小白推荐（我就是小白）

心理类：

《乌合之众》 人在小范围为私利行动 在民族范畴会抛开私利做出些过于崇高或粗鲁的行为 推荐

《原生家庭》 一个人受童年家庭的影响是最大的，这本书能看懂是一回事，能做好是另一回事