10X程序员工作法
2021-09-18 17:05:29 6 举报AI智能生成
10X程序员工作法是一种高效、创新的工作方法，旨在帮助程序员提高工作效率和创造力。该方法强调通过不断学习和实践，以及与同行交流和合作，来不断提升自己的技能和知识水平。同时，10X程序员工作法也注重培养良好的工作习惯和态度，如保持专注、积极主动、勇于尝试等。通过采用这种方法，程序员可以更快地完成任务，更好地解决问题，并在职业生涯中取得更大的成功。总之，10X程序员工作法是一种值得推广和应用的先进理念。
作者其他创作
大纲/内容
沟通反馈
为什么世界和你的理解不一样
我们努力地学习各种知识，为的就是更好地理解这个世界的运作方式，而沟通反馈，就是我们与真实世界互动的最好方式。
一个信息论视角的解释
信源（Information Source），它负责产生信息（Message）。
发送器（Transmitter），它会对信息进行某些操作，也就是对信息编码，产生信号（Signal）。
信道（Channel），它是信号传送的媒介
接收器（Receiver），它是对信号执行发送器的逆操作，解码信号，提取出信息
信宿（Destination），它负责接收信息。
因为每个人经历见识的差异，造成了各自编解码器的差异
改善编解码
这几乎是很多程序员讲东西的通病：讲东西直奔细节。
编解码器算法，也就是怎么协调沟通双方更有效地进行沟通。
，通过制定“完成的定义”就可以帮助改善这个过程。这就相当于，沟通的双方都有了一个编解码手册。
沟通反馈就是改善编码、解码以及算法的方式。
通过沟通反馈，不断升级自己的编解码能力。
你的代码为谁而写？
编写可维护的代码
计算机科学中只有两大难题：缓存失效和命名。
名字起得是否够好，一个简单的评判标准是，拿着代码给人讲，你需要额外解释多少东西。
代码到底是给谁写的？
任何人都能写出计算机能够理解的代码，只有好程序员才能写出人能够理解的代码。—— Martin Fowler
我们写代码的目的是与人沟通，因为我们要在一个团队里与人协同工作。
人要负责将业务问题和机器执行连接起来，缺少了业务背景是不可能写出好代码的。
虽然只是一个简单的名字修改，但从理解上，这是一步巨大的跨越，缩短了其他人理解这段代码所需填补的鸿沟，工作效率自然会得到提高。
用业务的语言写代码。
轻量级沟通：你总是在开会吗？
开会是为了解决问题，但真实情况却是开了会又没有解决多少问题，这真是一个奇特的矛盾。
凡是效果特别好的会议，基本上都是用来做信息同步的。
轻量级沟通
改善会议的第一个行动项是，减少参与讨论的人数。
如果你要讨论，找人面对面沟通。
站立会议
在有限的时间内，你能说什么呢？
我昨天做了什么？
我今天打算做什么？
我在过程中遇到了什么问题，需要请求帮助。
多面对面沟通，少开会。
可视化：一种更为直观的沟通方式
什么是技术雷达？
雷达图是一种很好的将知识分类组织的形式，它可以让你一目了然地看到并了解所有知识点
，并根据自己的需要，决定是否深入了解。
，并根据自己的需要，决定是否深入了解。
读书雷达
在我看来，雷达图不仅仅适用于组织，也可以适用于团队。
因为人的大脑更擅长处理图像。
可视化的优势
处理图像的速度远远快于处理文字
什么是看板？
多尝试用可视化的方式进行沟通。
快速反馈：为什么你们公司总是做不好持续集成？
快速反馈
执行同样的操作，本地环境会快于 CI 服务器环境。
只有 CI 服务器处于绿色的状态才能提交代码
不能把检查只放到 CI 服务器上执行
用好本地构建脚本（build script），保证各种各样的检查都可以在本地环境执行。
得到有效的反馈
反馈，也就是怎么得到有效的反馈。
持续集成监视器
怎么引人注目，怎么呈现。
CI 服务器一旦检查出错，要立即修复。
做好持续集成的关键在于，快速反馈。
开发中的问题一再出现，应该怎么办？
什么是复盘？
这种把过程还原，进行研讨与分析的方式，就是复盘。
用别人的视角看问题，这就是客体化。
回顾会议
所有给出的行动项应该都是可检查的，而不是一些无法验证的内容。
5 个为什么
定期复盘，找准问题根因，不断改善。
作为程序员，你也应该聆听用户声音
吃自家的狗粮
而作为一个程序员，欠缺用户视角，在与产品经理的交流中，你是不可能有机会的，因为他很容易用一句话就把你打败：“这就是用户需求。”
由听产品经理的话，扩大成倾听用户的声音。
这种改进很细微，如果你不是用户，只从逻辑推演的角度是很难看到这种差异的。
当你吃不到狗粮时
当产品还没有用户时
和产品经理没有“共同语言。”
谁离用户近，谁就有发言权，无论你的角色是什么。
多走近用户。
尽早暴露问题： 为什么被指责的总是你？
谁知道有问题？
不是所有的问题，都是值得解决的技术难题。
遇到问题，最好的解决方案是尽早把问题暴露出来。
Fail Fast
克服心理障碍
事情往前做，有问题尽早暴露。
结构化：写文档也是一种学习方式
你为什么不喜欢写文档？
很多人回避写文档的真正原因是，他掌握的内容不能很好地结构化。
将零散的知识结构化，有很多种方式，但输出是非常关键的一环。
知识输出
输出的过程，本质上就是把知识连接起来的过程。
金字塔原理
无他，唯手熟尔
多输出，让知识更有结构。
答疑解惑 | 持续集成，一条贯穿诸多实践的主线
1：单元测试做不好，是否会影响到 CI 的效果？
持续集成的价值在于，它是一条主线，可以将诸多实践贯穿起来。
什么叫测试防护网呢？就是你的测试要能给你提供一个足够安全的保障
，这也就意味着你要有足够多的测试。换个更技术点的术语来说
，就是要有足够高的测试覆盖率。
，这也就意味着你要有足够多的测试。换个更技术点的术语来说
，就是要有足够高的测试覆盖率。
所以，CI 作为一个单独的实践，本身是很简单的，但它可以成为提纲挈领的主线，帮助团队不断改善自己的开发过程。
2：老板参加复盘，不敢说真话怎么办？
暴露问题，是改进的前提条件。
3：国内的技术信息落后吗？
国内程序员真正落后的不是信息，而是观念。
总结
重点
看板
一种来自精益生产的可视化实践。
按阶段将任务放置其中。
可以帮助我们发现问题。
持续集成
做好持续集成的关键是，快速反馈。
本地检查通过之后再提交。
到有效的反馈方式，比如：CI 监视器。
持续集成的纪律。
只有 CI 服务器处于绿色的状态才能提交代码。
CI 服务器一旦检查出错，要立即修复。
回顾会议
软件团队复盘的一种实践。
枚举关注点，选出重点，深入讨论，列出行动项，找到负责人。
5 个为什么
又一个来自丰田的实践。
沿着一条主线追问多个问题。
用信息论理解沟通反馈
写代码的进阶路径
编写可以运行的代码。
编写符合代码规范的代码。
编写人可以理解的代码。
用业务语言写代码。
会议是一种重量级的沟通方式
减少参会人数。
找人面对面沟通。
聆听用户声音
能做自己用户，做自己的用户。
能接近用户，接近用户。
没有用户，创造用户。
Fail Fast
一种编写代码的原则。
出现问题尽早报错。
金字塔原理
从中心论点，到分论点，再到论据。
额外收获
持续集成是一条主线，可以将诸多实践贯穿起来。
从持续集成到稳定的开发分支，到频繁提交，足够小的任务，到任务分解。
从持续集成到可检查，到测试防护网，到测试覆盖率，到单元测试，到可测试代码，到软件设计。
安全性检查，是回顾会议的前提条件
在信息获取上，国内外程序员差别不大，开拓视野，改善工作习惯，是国内程序员亟需提高的。
自动化
你真的了解重构吗？
很多程序员对重构的理解是错的。
重构是一种微操作
你打算做的事叫重写（rewrite），而不是重构（refactoring）。
重构，本质上就是一个“微操作”的实践。
你需要把做的代码调整分解成若干可以单独进行的“重构”小动作，然后，一步一步完成它。
在这个分解出来的步骤里，每一步都可以很快完成，而且，每做完一步都是可以停下来的，这才是微操作真正的含义。
你需要有的是“把调整代码的动作分解成一个个重构小动作”的能力。
重构地图
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
函数式编程已然成为时代的主流。
锤炼你的重构技能。
“懒惰”应该是所有程序员的骄傲
不要自动化
做有价值的事是重要的，这里面的有价值，不仅仅是“做”了什么，通过“不做”节省时间和成本也是有价值的。
小心 NIH 综合症
做好自动化
你的日常工作是给别人打造自动化，但你自己的工作够自动化吗？
你要懂得软件设计
大多数人都是混淆了设计和实现。
在软件开发中，其它的东西都是易变的，唯有设计的可变性是你可以控制的。
请谨慎地将工作自动化
一个好的项目自动化应该是什么样子的？
最基本的项目自动化
生成 IDE 工程
编译
打包
运行测试
代码风格检查
测试覆盖率
数据库迁移
运行应用。
将你的工作过程自动化
程序员怎么学习运维知识？
有体系地学习运维知识。
持续交付：有持续集成就够了吗？
不同环境
（开发Dev环境）持续集成环境，持续集成是持续交付的前提，这个过程主要是执行基本的检查，打出一个可以发布的包。
测试环境（Test），这个环境往往是单机的，主要负责功能验证，这里运行的测试基本上都是验收测试级别的，而一般把单元测试和集成测试等执行比较快的测试放到持续集成环境中执行。
预生产环境（Staging），这个环境通常与生产环境配置是相同的，比如，负载均衡，集群之类的都要有，只是机器数量上会少一些，主要负责验证部署环境，比如，可以用来发现由多机并发带来的一些问题。
生产环境（Production），这就是真实的线上环境了。
将部署纳入开发的考量
如何做好验收测试？
行为驱动开发
如果你想做 BDD，就应该用业务语言进行描述。
用业务语言做系统测试，它是一个更高级别的抽象。
写好验收测试用例
想写好 BDD 的测试用例，关键点在用业务视角描述。
将验收测试自动化。
你的代码是怎么变混乱的？
逐步腐化的代码
你只是低着头完成了一项任务，而代码却变得更糟糕了
对程序员最好的惩罚是让他维护自己三个月前写的代码。
SOLID 原则
单一职责原则（Single responsibility principle，SRP）
开放封闭原则（Open–closed principle，OCP）
Liskov 替换原则（Liskov substitution principle，LSP）
接口隔离原则（Interface segregation principle，ISP）
依赖倒置原则（Dependency inversion principle，DIP）
单一职责原则
编写短函数
你能看到一个模块在为多少 actor 服务，就完全取决于你的分解能力了。
把函数写短。
总是在说MVC分层架构，但你真的理解分层吗？
设计上的分解
分层架构，实际上，就是一种在设计上的分解。
无处不在的分层
构建一个良好的抽象。
有抽象有发展
你的领域层只依赖于你的领域对象，第三方发过来的内容先做一次转换，转换成你的领域对象。
构建好你的领域模型。
为什么总有人觉得5万块钱可以做一个淘宝？
因为你们想的根本不是一个东西。
同样的业务，不同的系统
因为作为程序员，我们需要知道自己面对的到底是一个什么样的系统。
不同的业务量。
更准确地说，不同量级的系统根本就不是一个系统。
你用对技术了吗？
淘宝的工程师之所以要改进系统，真实的驱动力不是技术，而是不断攀升的业务量带来的问题复杂度
用简单技术解决问题，直到问题变复杂。
先做好DDD再谈微服务吧，那只是一种部署形式
怎么划分微服务，也就是一个庞大的系统按照什么样的方式分解
领域驱动设计
它把你的思考起点，从技术的角度拉到了业务上。
走向微服务
它限定了通用语言自由使用的边界，一旦出界，含义便无法保证。
持续集成、持续交付，然后呢？
1：持续交付是否可以再做扩展？
精益创业实际上是一种持续验证，验证想法的有效性，获得经过验证的认知（Validated Learning）。
2：Selenium 和 Cucumber 的区别是什么？
Selenium 是一个开源项目，它的定位是浏览器自动化，主要用于 Web 应用的测试。
它最早是 Jason Huggins 在 2004 年开发出来的，用以解决 Web 前端测试难的问题。
它最早是 Jason Huggins 在 2004 年开发出来的，用以解决 Web 前端测试难的问题。
Cucumber 的兴起伴随着 Ruby on Rails 的蓬勃发展，我们在之前的内容中提到过，
Ruby on Rails 是一个改变了行业认知的 Web 开发框架。所以，Cucumber 最初主要就是用在给 Web
应用写测试上，而 Selenium 刚好是用来操作浏览器的，二者一拍即合。
Ruby on Rails 是一个改变了行业认知的 Web 开发框架。所以，Cucumber 最初主要就是用在给 Web
应用写测试上，而 Selenium 刚好是用来操作浏览器的，二者一拍即合。
总结
持续交付
将生产部署纳入了开发的考量。
持续交付的基础设施通常包含持续集成环境、测试环境、预生产环境和生产环境
构建流水线保证到了下游的交付物一定是通过上游验证的。
随着 Docker 的诞生，交付由发布包变成了 Docker 镜像。
DevOps
将开发和运维结合到一起。
环境配置工具上的进步，让基础设施即代码成了行业共识。
验收测试
验收测试要站在业务的角度编写。
BDD 是一种编写验收测试的方式
Given…When…Then… 的描述给了一个描述业务的统一方式。
写好验收测试，需要构建测试模型。
SOLID 原则
设计模式背后的道理。
单一职责原则（Single responsibility principle，SRP）。
开放封闭原则（Open–closed principle，OCP）
Liskov 替换原则（Liskov substitution principle，LSP）
接口隔离原则（Interface segregation principle，ISP）
依赖倒置原则（Dependency inversion principle，DIP）
用好单一职责原则，前提条件是看待问题颗粒度要小
DDD
它将思考的起点拉到了业务上。
DDD 分为战略设计和战术设计。
微服务
做好微服务的前提是划分好限界上下文。
微服务的第一步，不要划分微服务。
综合运用
新入职一家公司，怎么快速进入工作状态？
运用思考框架
三个问题
Where are we?（我们现在在哪？）
Where are we going?（我们要到哪儿去？）
How can we get there?（我们如何到达那里？）
技术解决的是“怎么做”的问题，而我们第一个应该了解的问题是“做什么”。
三个小目标
业务
技术
团队运作
从大图景入手（由外到内）
业务
技术
团队运作
面对遗留系统，你应该这样做
分清现象与根因
它们只是现象，不是根因。
确定方案
先尝试重构你的代码，尽可能在已有代码上做小步调整，不要走到大规模改造的路上，因为重构的成本是最低的。
一方面，建立好领域模型，另一方面，寻找行业对于系统构建的最新理解。
建议
构建测试防护网，保证新老模块功能一致；
分成小块，逐步替换；
构建好领域模型；
寻找行业中关于系统构建的最新理解。
小步改造遗留系统，不要回到老路上。
我们应该如何保持竞争力？
焦虑的程序员
我们的焦虑来自于对未来的不确定性，而这种不确定性是一个特定时代加上特定行业的产物。
成为 T 型人
有了“一专”，“多能”才是有意义的，否则，就是低水平重复，而这正是很多人职业生涯不见起色的真正原因。
在学习区成长
如果你还什么都不会，那有一份编程的工作就好。
如果你已经能够写好普通的代码，就应该尝试去编写程序库。
如果实现一个具体功能都没问题了，那就去做设计，让程序有更好的组织
如果你已经能完成一个普通的系统设计，那就应该去设计业务量更大的系统。
如何在实际工作中推行新观念？
1：想要推行 DDD，阻力很大怎么办？
找到愿意和你一起改变的人，做一件具体的事。
Talk is cheap. Show me the code.
当你寻求改变时，无论你的角色是什么，你都需要扮演好领导者的角色，“Lead by Example”送给你！
2：测试怎么写？
外部系统对你来说，应该只是一个接口。
如果有任何外部系统，都要设计防腐层，用接口做隔离。
能模拟的就模拟，能本地的就本地。
关于外部系统的测试，你可以先通过接口隔离开来，然后，通过模拟服务或本地可控的方式进行测试。
“综合运用”主题内容的全盘回顾
“学习区”学习模型
舒适区，舒适而缺乏成长。
恐慌区，超出能力范围。
学习区，有难度而可以达成
在学习区练习才能得到足够的成长。
T 型人才，一专多能
知识的广度。
专业技能的深度。
有“一专”，“多能”才是有意义的。
进入新工作，从全面了解了解开始
业务：做什么。
技术：怎么做。
团队运作：怎么与人协作。
大到小，由外及内地了解工作。
面对遗留系统，稳扎稳打，小步前行
基础理念
烂代码只是现象，要了解根因。
能重构，先重构，大规模改造是迫不得已的选择。
小步前行。
实际操作
构建测试防护网。
将大系统分解成小模块，逐步替换。
新旧模块并存，由分发模块调度
建立好领域模型。
寻找行业对于系统构建的最新理解。
程序员的职业发展
程序员的焦虑来自于对未来的不确定性，这种不确定性是一个特定时代加上特定行业的产物。
快速发展的中国经济。
程序员在中国是一个新兴职业。
成为行业专家，制定高目标。
向大师学习，开拓视野。
找到好的问题，和高水平的人一起工作。
结束语
算法优化，其实就是尽可能利用已知的信息，少做不必要的事。
有效工作，需要我们把力量聚焦到正确的地方，做本质复杂度（Essential Complexity）的事情，少做无意义的事情。
开篇词
人月神话中的两个重要概念
本质复杂度（Essential Complexity）
偶然复杂度（Accident Complexity）
大部分程序员忙碌解决的问题，都不是程序问题，而是由偶然复杂度导致的问题。
四个原则
以终为始
任务分解
沟通反馈
自动化
在我看来，所有做软件的人能力都很强，这些问题都只是因为不会工作造成的，但更可怕的是，许多人深陷泥潭而不自知。
思考框架
10x程序员是如何思考的？
优秀程序员的开发效率是普通程序员的 10 倍。
三个问题
我现在是个什么水平？ --- 现状
我想达到一个什么水平？ --- 目标
我将怎样到达那个目标？ --- 实现路径
如果一个人能够清晰地回答出这三个问题，通常意味着他对要做的事有着清晰的认识。
产品经理的提问
为什么要做这个特性，它会给用户带来怎样的价值？
什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？
达成这个目的是否有其它手段？是不是一定要开发一个系统？
这个特性上线之后，怎么衡量它的有效性？
四个原则
以终为始
任务分解
沟通反馈
自动化
我们不是一个人孤独地在工作，而是与其他人在协作，想要做到高效工作，我们就要“抬起头”来，跳出写代码这件事本身。所以，我在开篇词里说，程序员解决的问题，大多不是程序问题。
面对问题时，用思考框架问问自己，现状、目标和路径。
以终为始
如何让你的努力不白费？
许多人都是刚刚听到别人要求做的一个功能，就开始脑补接下来的一切。导致的结果，就是付出的努力毫无意义。
一种反直觉的思维方式
想象的共同体
对做软件的人来说，我们应该把“终”定位成做一个对用户有价值的软件，能够为别人带来价值，自己的价值才能体现出来。
规划和发现
人类是一个擅长脑补的群体，一旦有人看到了这个文档，他就已经可以构想出这个平台已经存在的样子，进而给出各种各样的反馈：“我认为这个地方可以这样做”“我觉得那个地方可以改改”。
“以终为始”的方式，不仅仅可以帮我们规划工作，还可以帮我们发现工作中的问题。
践行“以终为始”就是在做事之前，先考虑结果，根据结果来确定要做的事情。
DoD的价值：你完成了工作，为什么他们还不满意？
完成的定义
DoD 是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况。
DoD 的检查项应该是实际可检查的
DoD 是团队成员间彼此汇报的一种机制。
站在 DoD 的肩膀上
它不仅局限在团队内部协作上，如果你可以放开思路，会发现 DoD 的思维在工作中用途非常广泛
DoD 是一个的思维模式，是一种尽可能消除不确定性，达成共识的方式。
在做任何事之前，先定义完成的标准。
接到需求任务，你要先做哪件事？
需求描述的问题
这种功能列表式的需求描述方式，将一个完整的需求敲成了碎片。
用户故事（User Story）
“用户故事”有什么用？
As a （Role）, I want to （Activity）, so that （Business Value）.
验收标准非常重要的一环是异常流程的描述。
验收标准给出了这个需求最基本的测试用例，它保证了开发人员完成需求最基本的质量。
如果你的团队采用用户故事的格式进行需求描述固然好，如果不能，在功能列表中，补充验收标准也会极大程度地改善双方协作的效率。
你的角色
扮演不同角色的时候，我们的思考模式是不同的。
最好维护的代码是没有写出来的代码。
在做任何需求或任务之前，先定好验收标准。
持续集成：集成本身就是写代码的一个环节
写代码是程序员的职责，但我们更有义务交付一个可运行的软件。
集成之“灾”
迈向持续集成
为什么他们要在开发一个月后才做集成呢？为什么不能在开发一周后，甚至是更短的时间内就集成一次？
Daily Build，每日构建。
倘若这个想法推演到极致，是否就变成了只要有代码提交，就去做集成？
“地面上”的持续集成
因为持续集成服务器的出现，反而可以做到每日构建。
虽然我们在同一个时代写代码做开发，但在技术实践层面，不同的团队却仿佛生活在不同的年代
。一个好的做法是尽早把代码和已有代码集成到一起，而不应该等着所有代码都开发完了，再去做提交。
尽早提交代码去集成。
精益创业：产品经理不靠谱，你该怎么办？
产品经理是个新职业
IT 行业中大多数人的专业程度是不够的。
我们必须要有自己的独立思考，多问几个为什么，尽可能减少掉到“坑”里之后再求救的次数。
软件开发的主流由面向确定性问题，逐渐变成了面向不确定性问题。
精益创业
它要解决的是面向不确定性创造新事物。
既然是不确定的，那你唯一能做的事情就是“试”。
精益创业提供给我们的是一个做产品的思考框架，我们能够接触到的大多数产品都可以放在这个框架内思考。
默认所有需求都不做，直到弄清楚为什么要做这件事。
解决了很多技术问题，为什么你依然在“坑”里？
“独善其身”不是好事
角色的差异
不同角色工作上真正的差异是上下文的不同。
虽然写的代码都一样，但你看到的是树木，人家看到的是森林，他更能从全局思考。
我并不是靠技术能力解决了问题，而是凭借对需求的理解把这个问题绕过去了。
而能想到问这样的问题，前提就是要跳出程序员角色思维，扩大自己工作的上下文。
当你对软件开发的全生命周期都有了认识之后，你看到的就不再是一个点了，而是一条线。
在更大的上下文工作
扩展自己工作的上下文，目光不再局限于自己的一亩三分地，还可以为自己的职业发展做好布局。
跳出程序员思维，这不仅仅是为了工作能够更高效，也是希望你有更好的发展机会。
扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上。
你的工作可以用数字衡量吗？
熟悉而陌生的数字
一些人说，自己靠直觉就能把事情做好，其实这是一种误解，因为那种所谓的直觉，通常是一种洞见（Insight），洞见很大程度上依赖于一个人在一个领域长期的沉淀和积累，而这其实是某种意义上的大数据。
人工智能：算法、算力和数据
而当事情复杂到一定程度时，简单地靠感觉是很难让人相信的。
从数字出发
为了从数字中发现问题，让系统更稳定。
问一下自己，我的工作是不是可以用数字衡量。
迭代0: 启动开发之前，你应该准备什么？
需求方面
1. 细化过的迭代 1 需求
2. 用户界面和用户交互
技术方面
1. 基本技术准备
持续集成
测试
2. 发布准备
数据库迁移
发布
日常工作
即便你做的不是一个从头开始的项目，对照这个清单，也会发现项目在某些项上的欠缺，可以有针对性地做一些补充。
设计你的迭代 0 清单，给自己的项目做体检。
答疑解惑 | 如何管理你的上级？
1：领导要求的，无力反驳怎么办？
2：产品经理总拿老板说事，怎么办？
不合理的部分应该是他和老板去沟通的，而不是让开发团队来实现。
3：别人能做的，我们也要做
第一，竞争对手有的产品，我们也要有。
第二：人家能做到，说明技术上是可行的。
总结
重点复习
DoD，确定好完成的定义，减少团队内部的理解不一致。
用户故事，细化出有价值的需求。
持续集成，通过尽早集成，减少改动量，降低集成的难度。
精益创业，减少过度开发不确定性产品带来的浪费。
迭代 0，在项目开始之前，做好一些基础准备。
思维转变
任何事物都要经过两次创造：一次是在头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation），然后才是付诸实践，也就是实际的构建或第二次创造（Physical/Second Creation）。
在更大的上下文内发现自己的“终”。
通过推演，找到通往“终”的路径。
用可度量的“数字”定义自己的“终”。
回顾
遇到事情，倒着想
在做任何事之前，先定义完成的标准。
在做任何需求或任务之前，先定好验收标准。
尽早提交代码去集成。
默认所有需求都不做，直到弄清楚为什么要做这件事。
扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上。
在动手做一件事之前，先推演一番。
问一下自己，我的工作是不是可以用数字衡量。
设计你的迭代 0 清单，给自己的项目做体检。
任务分解
向埃隆·马斯克学习任务分解
美国天文学家法兰克·德雷克（Frank Drake）
马斯克的任务分解
软件开发的任务分解
一个大问题，我们都很难给出答案，但回答小问题却是我们擅长的。
那么，用这种思路解决问题的难点是什么呢？给出一个可执行的分解。
不同的可执行定义差别在于，你是否能清楚地知道这个问题该如何解决。
如今软件行业都在提倡拥抱变化，而任务分解是我们拥抱变化的前提。
动手做一个工作之前，请先对它进行任务分解。
测试也是程序员的事吗？
谁要做测试？
测试人员应该做测试，这是没错的，但是测试只是测试人员的事吗？
内建质量（Build Quality In）
所以，对于每个程序员来说，只有在开发阶段把代码和测试都写好，才有资格说，自己交付的是高质量的代码。
自动化测试
会写代码，这个优势可以让我们把测试自动化。
这种测试框架最大的价值，是把自动化测试作为一种最佳实践引入到开发过程中，使得测试动作可以通过标准化的手段固定下来。
测试模型：蛋卷与金字塔
越是底层的测试，牵扯到相关内容越少，而高层测试则涉及面更广。
小事反馈周期短，而大事反馈周期长。
所以，虽然冰淇淋蛋卷更符合直觉，但测试金字塔才是行业的最佳实践。
当测试金字塔遇到持续集成
不是用单元测试框架写的测试就是单元测试
多写单元测试
先写测试，就是测试驱动开发吗？
测试驱动开发（Test Driven Development）
重构（refactoring）。
测试先行开发和测试驱动开发的差异就在重构上。
因为重构和测试的互相配合，它会驱动着你把代码写得越来越好。这是对“驱动”一词最粗浅的理解。
测试驱动设计
由测试驱动代码的编写。
抗拒测试的两个原因
第一，测试需要“额外”的工作量
第二，很多人会觉得代码太多不好测
我的代码怎么写才是能测试的，也就是说，我们要编写具有可测试性的代码。
一个好的解决方案是尽量不写 static 方法。
写代码之前，请先想想怎么测
我们应该编写可测的代码。
大师级程序员的工作秘笈
《测试驱动开发》
Kent Beck 的做法清晰而有节奏，每个任务完成之后，代码都是可以提交的。
而大多数程序员之所以开发效率低，很多时候是没想清楚就动手了。
很多人看了一些 TDD 的练习觉得很简单，但自己动起手来却不知道如何下手。中间就是缺了任务分解的环节。
微操作
任务分解的关键在于：小
如果你有了一个微习惯，坚持就不难了。
一个经过分解后的任务，需要关注的内容是有限的，我们就可以针对着这个任务，把方方面面的细节想得更加清晰。
微操作与分支模型
将任务拆小，越小越好。
一起练习：手把手带你分解任务
需求
开发任务清单
很多人可能更习惯一个类一个类的写，我要说，最好按照一个需求、一个需求的过程走，这样，任务是可以随时停下来的。
检验每个任务项是否拆分到位，就是看你是否知道它应该怎么做了。
每做完一个任务，代码都是可以提交的。
按照完整实现一个需求的顺序去安排分解出来的任务。
为什么你的测试不够好？
主要是因为这些测试不够简单。只有将复杂的测试拆分成简单的测试，测试才有可能做好。
简单的测试
测试写简单，简单到一目了然，不需要证明它的正确性。
前置准备、执行、断言和清理
测试的坏味道
这个测试一旦出错，就需要把所有相关的几个方法都查看一遍，这无疑是增加了工作的复杂度。
测试一定要有断言
你真正应该做的是，多写几个测试，每个测试覆盖一种场景。
一段旅程（A-TRIP）
编写可测试的代码。
要想写好测试，就要写简单的测试。
程序员也可以“砍”需求吗？
基本上，闯入你脑海的需求描述是主题（epic），在敏捷开发中，有人称之为主用户故事（master story）。
绝大多数问题都是由于分解的粒度太大造成的，少有因为粒度太小而出问题的。
需求要分解
INVEST 原则
用户故事，之所以是故事，就是要讲，要沟通。
需求的估算
估算的结果是相对的，不是绝对精确的，我们不必像做科研一样，只要给出一个相对估算就好。
一般来说，估算的过程也是大家加深对需求理解的过程。
想要管理好需求，先把需求拆小。
需求管理：太多人给你安排任务，怎么办？
最无脑的需求管理法：老板说的
就凭一句“老板说的”，我们就可以判断出，产品经理缺乏对需求管理应有的理解。
需求的优先级
按照时间管理的理念，重要且紧急的事情要立即做。重要但不紧急的事情应该是我们重点投入精力的地方。紧急但不重要的事情，可以委托别人做。不重要不紧急的事情，尽量少做。
如果不把精力放在重要的事情上，到最后可能都变成紧急的事情。
站在老板面前
当员工想不明白的事，换成老板的视角就全明白了。
尽量做最重要的事。
如何用最小的代价做产品？
最小可行产品（Minimum Viable Product，MVP）
最小的代价
我们要做的是验证一个想法的可行性，甚至不是为了开发一个软件，开发软件只是一种验证手段。
这个团队验证了一大堆的想法，而代码却是一行都没有写，所有花费的工作量都是有针对性的验证。
可行的路径
不是一个模块做得有多完整，而一条用户路径是否通畅。
当时间有限时，我们需要学会找到一条可行的路径，在完整用户体验和完整系统之间，找到一个平衡。
想要在实践中运用好最小可行产品的理念，就是要用最小的代价找到一条可行的路径。
做好产品开发，最可行的方式是采用 MVP。
答疑解惑 | 如何分解一个你不了解的技术任务？
1：面对不了解的技术，我该如何分解任务？
答案很简单，先把它变成你熟悉的技术
做一次技术 Spike
Spike 的作用就在于消除不确定性，让项目经理知道这里要用到一项全团队没有人懂的技术，需要花时间弄清楚。
这项技术在项目中应用场景和我们的关注点。
请丢弃掉你的原型代码
2：项目时间紧，该怎么办？
混淆了目标与现状
假设现在不忙了，你知道该怎么改进吗？
3：多个功能同时开发，怎么办？
在主分支开发模型中，有一些常见的解决多功能并行开发的方法，其中，Feature Toggle 是最常用的一个，也就是通过开关，决定哪个功能是对外可用的。
总结
重点复习
测试金字塔
测试驱动开发
艾森豪威尔矩阵（Eisenhower Matrix）
最小可行产品
应用的做法和评判标准
尽量不写 static 方法；
主分支开发模型是一种更好的开发分支模型；
好的用户故事应该符合 INVEST 原则；
估算是一个加深对需求理解的过程，好的估算是以任务分解为基础的；
好的测试应该符合 A-TRIP。
改善自己的开发工作
分而治之，是人类解决问题的基本手段；
软件变更成本，它会随着时间和开发阶段逐步增加；
测试框架把自动化测试作为一种最佳实践引入到开发过程中，使得测试动作可以通过标准化的手段固定下来；
极限编程之所以叫“极限”，它背后的理念就是把好的实践推向极限；
大师级程序员的工作秘笈是任务分解，分解到可以进行的微操作；
按照完整实现一个需求的顺序安排开发任务。
额外收获
对不了解技术的任务，先要去了解技术，然后再做任务分解；
通过一次技术 Spike ，学习新技术；
丢弃掉在 Spike 过程中开发的原型代码；
分清目标与现状，用目标作为方向，指导现状的改变；
多个功能并行开发可以考虑使用 Feature Toggle；
在遗留系统上做改造可以考虑使用 Branch by Abstraction 。
职业：暂无
0 条评论
下一页
