持续交付

四个原则：

以终为始

任务分解

沟通反馈

自动化

 

细目：

先考虑结果，根据结果确定要做的事情

定义完成的标准，定义验收的标准（用户故事），持续集成

搞清楚为什么做这件事

不同角色工作真正的上下文不同，跳出程序员思维，扩大自己的上下文

单一维度的思考，在多维思考者的眼里几乎就是漏洞百出的

通向结果的路径才是更重要的（比如思考上线问题）

工作能否通过数字衡量

开发前先做准备，需求能落地

高手全是微操作，先对任务进行分解

测试集成，包括开发和测试

写代码之前，先想想怎么测试，编写可测试的代码

任务拆解，小而可行；分解是硬功夫，需要不断练习；达到代码可提交

测试标准：自动化 全面 可重复 独立 专业

用户故事，有背景，需要讲和沟通

需求这个东西，你 认为 没法砍，那就真没法砍了

需求：重要 和 紧急，重要大于紧急

你不主动，你就被动

先验证需求可行性，再动手写代码

寻找一条可靠路径，在完整用户体验和完整系统之间，找到一个平衡

程序员不反抗，他们就意识不到自己的糊涂

沟通反馈，改善编码、解码以及算法的方式

代码级别：可运行 符和规范 可理解 业务语言流程

好的会议，是用来同步信息的；多面对面沟通，少开会

可视化沟通：技术看板

心流：感受不到时光流逝

复盘：客体化；定期复盘，找准问题原因，不断改善

由听产品经理的话，扩大成倾听用户的声音；谁离用户近，谁就有发言权，无论角色是什么

提前把问题暴露出来，Fail Fast。把问题解决，而不是掩盖问题

结构化输出，让知识更有结构

软件开发过程中，软件设计的可变性是可控制的

体系化学习：语言 核心库 第三方库 开发框架 单机部署 集群部署

持续交付：持续集成环境 测试环境 预生产环境 生产环境（DevOps 部署纳入开发的考量）

写代码这件事，可当成手艺活不断打磨

代码治理，单一职责 开放封闭 替换原则 接口隔离 依赖倒置 | 设计模式是术 设计原则是道

分层价值：构建一个良好的抽象，领域模型（本质上是由于人的认知能力有限，不得已而为之）

不同量级的系统，不是一个系统

业务划分与微服务实现

业务是大图景，架构是划分出来的，比如外部接口和内部业务流程

遗留代码就是没有测试的代码

先重构，再重写

一专多能，在学习区工作和成长。成为专家，路才能越走越宽，否则，只能步履维艰。工作是属于公司的，而职业生涯却是属于自己的

持续集成 交付 验证

学会管理上级：管理预期 说出想法 讲清楚场景

不合理的部分学会沟通，而不是一味地去实现

区分需求和技术