10x程序员工作法(高效工作方法)
摘抄分为四部分
整篇博客的学习收获集中在 对需求的重视(工程师的角度) 和 提升工作效率方法论的学习;对第四模块自动化及提及篇幅较大的 测试和集成 比较模糊, 因为实际使用中已经是最成熟实践, 对文中提及的过去的集成测试演进史还是比较陌生
主体
软件行业里有一本名著叫《人月神话》，其中提到两个非常重要的概念：本质复杂度（Essential Complexity）和偶然复杂度（Accident Complexity）。简单来说，本质复杂度就是解决一个问题时，无论怎么做都必须要做的事，而偶然复杂度是因为选用的做事方法不当，而导致要多做的事。比如你要做一个网站，网站的内容是你无论如何都要写的，这就是“本质复杂度”。而如果今天你还在用汇编写一个网站，效率是不可能高起来的，因为你选错了工具。这类选错方法或工具而引发的问题就是“偶然复杂度”。我会尝试给你提供一个思考框架，帮你在遇到问题时梳理自己真正要做的事情。围绕着这个框架，我还会给你一些原则。这些原则，是我从软件行业的诸多软件开发最佳实践中总结出来的，也是我如今在工作中所坚持的。这些原则就是一条主线，将各种最佳实践贯穿起来。
以终为始
任务分解
分解任务时注重粒度足够小, 达成可实施性
--> 有关 测试驱动开发 的测试分解
软件开发工程师需要有对需求的重视, 将从产品手上结果需求看做开发第一步, 认真审视需求合理性, 做需求分解, 评估需求难度
沟通反馈
意识到世界各处存在认知偏差, 通过 沟通反馈 来矫正偏差, 关键在于 发送方的信息更准确, 接收方的理解更明白, 且双方有相同的理解标准(Dod), 类比编码解码译码
提升方法论
上下文
在更大的上下文中工作，也就是想让人获得更多的思考维度思考框架
运用这个思考框架，我们需要问自己一些问题：(现状,目标,实现路径)
- Where are we going?（我们要到哪儿去？）
- How can we get there?（我们如何到达那里？）
为了把这个框架应用在我们程序员的工作中,四个思考原则：面对问题时，用思考框架问问自己，现状、目标和路径。
艾森豪威尔矩阵
按照时间管理的理念，重要且紧急的事情要立即做。重要但不紧急的事情应该是我们重点投入精力的地方。紧急但不重要的事情，可以委托别人做。不重要不紧急的事情，尽量少做。这个矩阵带给我们思维上最大的改变是，让人意识到事情和事情不是等价的。如果不把精力放在重要的事情上，到最后可能都变成紧急的事情。
可视化雷达
5个为什么
你的团队如果能一下洞见到根因固然好，如果不能，那么最好多问一些为什么。具体怎么问，有一个常见的做法是：5个为什么（5 Whys）。这种做法是丰田集团的创始人丰田佐吉提出的，后来随着丰田生产方式而广为人知。
为什么要多问几个为什么？因为初始的提问，你能得到的只是表面原因，只有多问几个为什么，你才有可能找到根本原因。我给你举个例子。服务器经常返回504，那我们可以采用“5个为什么”的方式来问一下。- 为什么会出现504呢？因为服务器处理时间比较长，超时了。
- 为什么会超时呢？因为服务器查询后面的 Redis 卡住了。
- 为什么访问 Redis 会卡住呢？因为另外一个更新 Redis 的服务删除了大批量的数据，然后，重新插入，服务器阻塞了。
- 为什么它要大批量的删除数据重新插入呢？因为更新算法设计得不合理。
- 为什么一个设计得不合理的算法就能上线呢？因为这个设计没有按照流程进行评审。
问到这里，你就发现问题的根本原因了：设计没有经过评审。找到了问题的原因，解决之道自然就浮出水面了：一个核心算法一定要经过相关人员的评审。当然，这只是一个例子。有时候，这个答案还不足以解决问题，我们还可以继续追问下去，比如，为什么没有按流程评审等等。所以，“5个为什么”中的“5”只是一个参考数字，不是目标。“5个为什么”是一个简单易上手的工具，你可能听了名字就知道该怎么用它。有一点需要注意的是，问题是顺着一条主线追问，不能问5个无关的问题。无论是“回顾会议”也好，“5个为什么”也罢，其中最需要注意的点在于，不要用这些方法责备某个人。我们的目标是想要解决问题，不断地改进，而不是针对某个人发起情感批判。
写文档
锻炼 结构整理 --> 输出知识进行锻炼, 接收反馈查漏补缺 --> 采用 金字塔 的方法论, 从中心论点出发向下总结分论点, 然后进行论据概述如果今天的内容你只能记住一件事，那请记住：多输出，让知识更有结构。
T型人才
一专多能
学习区模型
需求处理(开发与产品的纠纷)
走近用户
将产品面向用户, 倾听用户的体验, 甚至将自己作为用户进行问题采集;将从用户收集来的问题作为通用语言, 来协调产品经理的 业务语言 和开发人员的 计算机语言, 站到平等地位讨论需求
需求开发
改动量过大, 拖延集成时间 --> 缩短集成的代码改动量, daily build 每日构建 --> 每次提交代码都进行构建, 持续集成服务器
产品的紧急需求
最小可行产品（Minimum Viable Product，MVP）
最小: 体现在投入的劳动力足够小, 基于产品原型和用户交互进行沟通确立需求, 而不需要进行实际的开发可行:不是一个模块做得有多完整，而一条用户路径是否通畅, 可以对产品进行垂直切分, 完成一条执行交互
团队开发方法论
管理上级
1.分析利弊, 如果压缩时间需要付出某个代价, 比如去掉一个边缘特性, 或者先上线临时版本, 后续补齐
Dod
Definition of done
因为对"完成"的认知偏差导致的偏离预期, 通过定义Dod -- 可检查的事项完成列表来达成对结果的多方共识, 即定义完成的标准
沙盘演算
最后一公里:完成一件事，在最后也是最关键的步骤
- 推演出一个可以一步一步执行的上线方案，用前面考虑到的因素作为衡量指标。
- 在做一个产品之前，先来推演一下这个产品如何推广，通过什么途径推广给什么样的人；
- 在做技术改进之前，先来考虑一下上线是怎样一个过程，为可能出现的问题准备预案；
- 在设计一个产品特性之前，先来考虑数据由谁提供，完整的流程是什么样的。
使用 数字 衡量指标
一些人说，自己靠直觉就能把事情做好，其实这是一种误解，因为那种所谓的直觉，通常是一种洞见（Insight），洞见很大程度上依赖于一个人在一个领域长期的沉淀和积累，而这其实是某种意义上的大数据。
开发步骤0
尽早暴露问题
Fail Fast 是一个重要的编程原则：遇到问题，尽早报错。不要以构建健壮系统为由，兼容很多奇怪的问题，使得 Bug 得以藏身。
快速上手新公司
从大到小、由外而内
找到同样愿意改变的人, 从一个小的 example 做起
10个月宝宝每天需要喝多少奶粉？
