四个原则:
以终为始
任务分解
沟通反馈
自动化
细目:
先考虑结果,根据结果确定要做的事情
定义完成的标准,定义验收的标准(用户故事),持续集成
搞清楚为什么做这件事
不同角色工作真正的上下文不同,跳出程序员思维,扩大自己的上下文
单一维度的思考,在多维思考者的眼里几乎就是漏洞百出的
通向结果的路径才是更重要的(比如思考上线问题)
工作能否通过数字衡量
开发前先做准备,需求能落地
高手全是微操作,先对任务进行分解
测试集成,包括开发和测试
写代码之前,先想想怎么测试,编写可测试的代码
任务拆解,小而可行;分解是硬功夫,需要不断练习;达到代码可提交
测试标准:自动化 全面 可重复 独立 专业
用户故事,有背景,需要讲和沟通
需求这个东西,你 认为 没法砍,那就真没法砍了
需求:重要 和 紧急,重要大于紧急
你不主动,你就被动
先验证需求可行性,再动手写代码
寻找一条可靠路径,在完整用户体验和完整系统之间,找到一个平衡
程序员不反抗,他们就意识不到自己的糊涂
沟通反馈,改善编码、解码以及算法的方式
代码级别:可运行 符和规范 可理解 业务语言流程
好的会议,是用来同步信息的;多面对面沟通,少开会
可视化沟通:技术看板
心流:感受不到时光流逝
复盘:客体化;定期复盘,找准问题原因,不断改善
由听产品经理的话,扩大成倾听用户的声音;谁离用户近,谁就有发言权,无论角色是什么
提前把问题暴露出来,Fail Fast。把问题解决,而不是掩盖问题
结构化输出,让知识更有结构
软件开发过程中,软件设计的可变性是可控制的
体系化学习:语言 核心库 第三方库 开发框架 单机部署 集群部署
持续交付:持续集成环境 测试环境 预生产环境 生产环境(DevOps 部署纳入开发的考量)
写代码这件事,可当成手艺活不断打磨
代码治理,单一职责 开放封闭 替换原则 接口隔离 依赖倒置 | 设计模式是术 设计原则是道
分层价值:构建一个良好的抽象,领域模型(本质上是由于人的认知能力有限,不得已而为之)
不同量级的系统,不是一个系统
业务划分与微服务实现
业务是大图景,架构是划分出来的,比如外部接口和内部业务流程
遗留代码就是没有测试的代码
先重构,再重写
一专多能,在学习区工作和成长。成为专家,路才能越走越宽,否则,只能步履维艰。工作是属于公司的,而职业生涯却是属于自己的
持续集成 交付 验证
学会管理上级:管理预期 说出想法 讲清楚场景
不合理的部分学会沟通,而不是一味地去实现
区分需求和技术