10x engineers 技术雷达 在过去的几个月中，10倍工程师一词受到了密切的关注。一个广泛传播的推文讨论在实质上建议公司应原谅反社会和破坏性的行为，以留住被认为个人产出巨大的工程师。幸运的是，许多人在社交媒体上都嘲笑了这个概念，但是“明星开发者”的刻板印象仍然普遍存在。根据我们的经验，伟大的工程师不是因为个人产出而是因为能在优秀的团队中合作而诞生。打造一支混合不同经验和背景，但成员才华横溢的团队，并为团队合作、学习和持续改进提供良好的助力，这会是更行之有效的方式。这些10倍团队行动起来更快，弹性也更强——而无需屈从错误的行为。
概述
本质复杂度 Essential Complexity
偶然复杂度 Accident Complexity
选择正确的做事方法，减少偶然复杂度带来的工作量； 原则
- 以终为始
- 任务分解
- 沟通反馈
- 自动化
思考框架
- Where are we ?
- Where are we going ?
- How can we get there ?
以终为始
如何让努力不白费？
任何事情都要经过两次创造：一次是在脑中，是智力上的创造，然后才是付诸实践，也就是实际的构建
对做软件的人来说，我们应该把”终”定位成做一个对用户有价值的软件，能够为别人带来价值，自己的价值才能体现出来。
tips:设计一个以终为始的项目或示例
DoD 的价值
Definition of Done
User Story
使用情景演绎的方式，完善需求
- 主题
- 概述
- 详述
- 验收标准
验收标准中，非常重要的是异常流程的描述，类似于测试用例中的异常逻辑验证。
持续集成
研发需要交付的，不是一堆代码文件，而是可以运行的软件或系统。 虽然我们在同一个时代写代码做开发，但在技术实践层面，不同的团队却仿佛生活在不同的年代
精益创业
IT行业中大多数人的专业程度是不够的。我们必须要有自己的独立思考，多问几个为什么，尽可能减少掉到坑里之后再求救的次数。
精益创业：面向不确定性创造新事物。精益创业提供给我们的是一个做产品的思考框架，我们能够接触到的大多数产品都可以放在这个框架内思考。
build—measure—learn 循环
默认所有需求都不做，直到弄清楚为什么要做这件事。
坑里坑外
角色的差异:不同角色工作上的真正差异是上下文的不同。同样是写代码，有的人看到的是树木，有的人看到的是森林，能够从全局思考。
手里有一把锤子，满世界都是钉子。
花费很大力气去解决一个可能并不是问题的问题，常常是很多程序员的盲区。
演绎
最后一公里：如果想要达到目标，最后我们要做的是什么
- 从结果入手，看看最终上线需要考虑哪些因素
- 演绎出一个可以一步步执行的方案，用前面考虑到的因素作为衡量标准
- 根据演绎出来的方案，总结要做的任务 以终为始，但通往结果的路径更加重要。
量化
洞见（Insight）:依赖于一个人在一个领域长期的沉淀和积累，其实是某种意义上的大数据。
Planning&Prepare
设计自己的迭代0清单
任务分解
银河系中，有多少与我们相近的文明。德雷克公式： N= R* x Fp x Ne x f1 x fi x l
埃隆马斯克的火星探测计划：把一个人从地球送到火星，成本降低100万倍。
测试
对每个程序员来说，只有在开发阶段把代码和测试都写好了，才有资格说，自己交付的是高质量的代码。 冰淇淋蛋卷测试模型： 费时费力的测试模型
- 手动回归测试
- 自动化端到端测试
- 集成测试
- 单元测试
- UI
- 服务
- 单元
越是底层的测试，牵扯的相关内容越少，而高层测试则涉及面更广。 多写单元测试
TDD 测试驱动开发
测试驱动代码：一个static方法示例，如何测试一个static方法，OOP的思想下如何更好的完成。
Test Driven Development
Test Driven Design
编写可测试的代码
大师级程序员秘籍
- TDD从而来？
- 《解析极限编程》
- 《测试驱动开发》
将任务分解，越小越好。
任务分解练习
需求：用户通过输入用户名、密码登陆。
优秀的测试代码
一段旅程 A-TRIP
- Automagic
- Thorough
- Repeatable
- Independent
- Professional
砍需求
用户故事的评价原则：
INVEST
- Independent
- Negotiable 可协商的
- Valuable
- Estimatable
- Small
- Testable
想要管理好需求，先把需求拆小
需求的估算，怎么做才会比较合理，误差最小？
推荐书籍
需求管理
需求优先级管理，重要程度、紧急程度
最小代价
MVP：Minimum Viable Product 最小可行产品
沟通反馈
人生不如意，十之八九。
沟通反馈就是改善编码、解码以及算法的方式。
编写可维护的代码
任何人都可以写出计算机能够理解的代码，只有优秀的程序员才能写出人能够理解的代码 ------Martin Fowler
用业务语言编程
领域驱动设计：Domain Driven Design
推荐阅读 《代码整洁之道》—Robert Martin
22 轻量级沟通：为什么总是在开会
开会是为了解决问题，但真实情况是开了会没有解决多少问题，却产生了会议过多的问题
凡是效果特别号的会议，都是用来做信息同步的；效果不好的会议，基本都是用来讨论的。
改善会议：
- 减少参会人数
- 当面沟通
- 站立会议
可视化：一种更为直接的沟通方式
技术雷达：结构化学习新知识的方式
快速反馈：如何做好持续集成
- 持续集成监视器，实时显示持续集成的状态
- 遇到问题立即响应
复盘
不要被同样的招数击败两次 复盘的好处：客体化，用别人的视角看问题
复盘：过程还原，进行研讨与分析，找到自我改进方法的一个方式。这种方式拥有客体化的视角，能够更客观的看待曾经发生的一切。
定期复盘，找准问题的根本原因，不断改善。
倾听用户的声音
谁离用户近，谁就有发言权，无论你是什么角色
多走进用户
产品经理是用户需求的传声筒
Fail Fast
如果有问题，那就尽早的将问题暴露出来。
越早的暴露问题，解决问题的成本就越低。
结构化学习：会写文档
将零散的知识结构化有很多种方式，输出是非常关键的一环。
如何写好文档：无他，唯手熟尔。
推荐阅读
懒惰的天性
做有价值的事是最重要的，这里的有价值，不仅仅是做了什么，通过不做节省时间和成本也是有价值的。
从日常工作中的自动化开始，打造自己的自动化利器
给别人打造自动化工具中需要具备的能力：软件设计
在软件开发中，其他的东西都是易变的，唯有设计的可变性的可变性是自己可以控制的。
优秀程序员的三大美德：懒惰、急躁和傲慢。
项目自动化
将工作过程自动化。
零散的运维知识
将零散的运维知识系统化，怎么系统化？
持续交付 ≠ 持续集成
如何构建持续交付系统
将部署纳入开发的考量
测试验收
BBD: Behavior Driven Development BBD 测试框架 Cucumber
关键一点：将验收测试自动化
逐步腐化的代码
对程序员最好的惩罚是让他维护自己三个月前写的代码
软件设计原则: SOLID
- Single responsibility principle
- Open-closed principle
- Liskov subsitution principle
- Interface segregation principle
- Dependency inversioni principle 将函数写短
MVC 封层设计
分层的价值：构建一个良好的抽象
如何使用5万块做一个淘宝
推荐书籍《淘宝技术这十年》
不同量级的系统，根本不是一个系统
用简单的技术解决问题，直到问题变复杂
做好DDD 再谈微服务
DDD: Domain Driven Design 领域驱动设计
推荐书籍
如何维护系统
改造遗留系统，一个关键点就是，不要回到老路上。
书籍推荐
如何保持竞争力
一专多能，成为T字型人才
在学习区工作和成长。
