10x程序员工作法
2021-10-13 00:34:23 2 举报AI智能生成
10x程序员工作法学习笔记
作者其他创作
大纲/内容
1. 以终为始
遇到事情，倒着想
在做任何事之前，先定义完成的标准。
DOD
在做任何需求或任务之前，先定好验收标准。
尽早提交代码去集成
默认所有需求都不做，直到弄清楚为什么要做这件事。
扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上
在动手做一件事之前，先推演一番
管理上级
管理上级预期
告诉他如果需要压缩时间，则会牺牲什么，有什么样的影响
帮助上级丰富知识
说出你的想法
思维转变
两次创造
头脑中的创造（Mental/First Creation）
付诸实践（Physical/Second Creation）
在更大的上下文内发现自己的“终”
通过推演，找到通往“终”的路径
用可度量的“数字”定义自己的“终”
2. 任务分解
方法
1. 分而治之，动手之前先进行任务分解
2. 多写单元测试，将粒度变细
3. 将任务拆小，越小越好
每做完一个任务，代码都是可以提交的
4. 按照完整实现一个需求的顺序去安排分解出来的任务
5. 把控需求，先把需求拆分
6. 划分任务等级，只做最重要的事
7. 做好产品开发，采用MVP
MVP 就是最小可行产品，Deadline 是形式，MVP 是内核。
最佳实践
测试金字塔
行业中测试组合的最佳实践
多写单元测试是关键
测试驱动开发
测试驱动开发的节奏是：红——绿——重构，重构是测试驱动开发区别于测试先行的关键。
有人把测试驱动开发理解成测试驱动设计，它给行业带来的思维改变是，编写可测的代码。
艾森豪威尔矩阵（Eisenhower Matrix）
将事情按照重要和紧急进行划分。
重要但不紧急的事情应该是我们重点投入精力的地方
紧急但不重要的事情，可以委托别人做。
不重要不紧急的事情，尽量少做。
最小可行产品
“刚刚好”满足客户需求的产品。
在实践中，要用最小的代价找到一条可行的路径。
重要思想
分而治之，是人类解决问题的基本手段
软件变更成本，它会随着时间和开发阶段逐步增加；
测试框架把自动化测试作为一种最佳实践引入到开发过程中，使得测试动作可以通过标准化的手段固定下来；
极限编程之所以叫“极限”，它背后的理念就是把好的实践推向极限；
大师级程序员的工作秘笈是任务分解，分解到可以进行的微操作；
按照完整实现一个需求的顺序安排开发任务。
3. 沟通反馈
通过沟通反馈，不断升级自己的编解码能力。
编写可以运行的代码
编写符合代码规范的代码
编写人可以理解的代码
用业务语言编写代码
多尝试用可视化的方式进行沟通
看板
一种来自精益生产的可视化实践。
按阶段将任务放置其中。
可以帮助我们发现问题。
技术雷达
做好持续集成，快速反馈
定期复盘，找准问题根因，不断改善
5why?
先对比实际结果和期初所定目标之间有什么差距
情景再现，回顾项目的几个阶段
每个阶段进行得失分析，找出问题原因
总结规律，化作自己的技能沉淀，再次遇到时可以规避
复盘资料应该记录到知识库
面对面沟通
十分钟站会
做了什么
要做什么
遇到问题
多走进用户
能做自己用户，做自己的用户
能接近用户，接近用户
没有用户，创造用户
事情往前做，有问题尽早暴露
一种编写代码的原则：Fail Fast
多输出文字，让知识有结构
4. 自动化
与机器交互的
DevOps
开发（Development）和运维（Operations）组合
一种软件交付的理念和方法，目的是增强软件的可靠性
方法
1. 谨慎地将工作自动化
了解一个技术，不是简单的了解其的实现，更是掌握它的设计
2. 将你的工作过程自动化
3. 有体系地学习运维知识
4. 持续交付，将部署纳入开发的考量
5. 将验收测试自动化
6. 把函数写短，道和术的结合
7. 构建好你的领域模型
三层设计，设计上的分解
拆分问题为小问题
目的：为了提供抽象
8. 用简单技术解决问题，直到问题变复杂
理解业务，不低估业务复杂度
理解技术，不增加技术复杂度
9. 学习领域驱动设计。
重构代码
SOLID 原则
单一职责原则（Single responsibility principle，SRP）
开放封闭原则（Open–closed principle，OCP）
Liskov 替换原则（Liskov substitution principle，LSP）
接口隔离原则（Interface segregation principle，ISP）
依赖倒置原则（Dependency inversion principle，DIP）
设计模式
5. 综合运用
入职新公司
利用思考框架
1. 目标
2. 现状
3. 实现方式
切分目标
1. 业务
业务是做什么的，解决什么样的问题，具体的业务流程是什么样子的
2. 技术
技术栈
构建脚本，代码结构
业务架构
系统需要集成哪些外部系统
系统对外提供哪些接口
内部模块
模块划分
模块职责
分层抽象
3. 团队运作
需求是从哪来的
产品最终会由谁使用
团队需要向谁汇报
内部的活动
定期的活动，比如，站会、回顾会议、周会时间安排
团队的日常活动，比如，是否有每天的代码评审、是否有内部的分享机制
保持竞争力
T 型人：一专多能
知识的广度
技能的深度
在学习区成长
事情有难度，又刚好是你努力一下可以完成的
职业发展
成为行业专家，制定高目标
向大师学习，开拓视野
找到好的问题，和高水平的人一起工作
改造遗留系统
基础理念
烂代码只是现象，要了解根因
能重构，先重构，大规模改造是迫不得已的选择
实际操作
构建测试防护网，保证新老模块功能一
分成小块，逐步替换
构建好领域模型
寻找行业中关于系统构建的最新理
6. 推荐书籍
金字塔原理
从中心论点，到分论点，再到论据。
编码实践
《代码整洁之道》
《实现模式》
《程序设计实践》
《卓有成效的程序员》
设计
《敏捷软件开发：原则、实践与模式》
《架构整洁之道》
《Head First 设计模式》
《企业应用架构模式》
《Unix 编程艺术》
工程实践
《解析极限编程》
《重构：改善既有代码的设计》
《重构与模式》
《测试驱动开发》
《持续交付 2.0》
《修改代码的艺术》
领域驱动设计
《领域驱动设计》
《实现领域驱动设计》
《领域驱动设计精粹》
产品与需求
《精益创业》
《精益创业实战》
《Scrum 敏捷软件开发》
《用户故事与敏捷方法》
《敏捷软件开发实践 估算与计划》
子柳《淘宝技术这十年》
开发文化
《人月神话》
《大教堂与集市》
《程序员的职业素养》
软件开发拾遗
《计算机程序设计艺术》
《快速软件开发》
《C 程序设计语言》
《Unix 编程环境》
《淘宝技术这十年》
7. Something Interesting
本质复杂度（Essential Complexity）和偶然复杂度（Accident Complexity）
DoD（Definition of Done，完成的定义）
德雷克公式
技术雷达
过程还原，进行研讨与分析的方式，就是复盘。
Eat your own dog food（从1988年开始，这个说法开始在 IT 行业流行的，微软的保罗·马瑞兹（Paul Maritz）写了一封“Eating our dog food”的邮件，提到要“提高自家产品在内部使用的比例。”从此，这个说法在微软迅速传播开来。）
写程序有一个重要的原则叫 Fail Fast，这是什么意思呢？就是如果遇到问题，尽早报错。
靠 debug 来定位问题是最为费时费力的一种做法。
能力成熟度模型（Capability Maturity Model for Software）
当你的技术知识积累到一定程度时，还采用原来的学习方式，就很难获得真正意义上的提高，这是很多人抱怨 IT 行业不好混的原因。
重构，本质上就是一个“微操作”的实践。另立门户，重新实现这套系统。对不起，你打算做的事叫重写（rewrite），而不是重构（refactoring）。
优秀程序员应该有三大美德：懒惰、急躁和傲慢（Laziness, Impatience and hubris）
学习增量
DDD 分为战略设计（Strategic Design）和战术设计（Tactical Design）
0 条评论
下一页
