- 开发新需求前的四个思考原则（不能自答出来就问产品经理）
这个功能不做会怎么样？有没有什么替代方案？ - DoD（Definition of Done，完成的定义）
在做事前，先定义完成的标准，达成对”完成”的一致理解，包括上下级关系中、内外部合作关系中、产品与开发关系中、同事关系中对一件事一个功能需求的理解一致，具体可以采用一个可检查的清单，确保不会遗漏任何事情，也叫验收标准。 务必主动告知对方自己对”完成”的理解 - 扩大自己工作的上下文，别把自己局限在一个”程序员”的角色上
理解不同角色的工作模式和工作细节，不断扩大自己工作的上下文，在一个局部上下文难以解决的问题，换到另外一个上下文甚至是可以不解决的。比如在开发上的一个技术难题需要费很大力气才能解决，但如果和产品沟通较好，换一种实现方式，问题也许就迎刃而解。 - 沙盘推演
1 在做一个产品之前，先来推演一下这个产品如何推广，通过什么途径推广给什么样的人
2 在做技术改进之前，先来考虑一下上线时怎样一个过程，为可能出现的问题准备预案（即开发的最后一公里）
3 在设计一个产品特性之前，先来考虑数据由谁提供，完整的流程是什么样的 - 开发的最后一公里
1 接到需求时，先从结果的角度入手，看看最终上线要考虑哪些因素
2 推演出一个可以一步一步执行的上线方案，用前面考虑到的因素作为衡量指标
3 根据推演出来的上线方案，总结要做的任务 - 用数字衡量工作，少用甚至不用”可能、应该”，可以提升沟通效率
- 迭代 0 清单，开发前的准备
- 动手前先进行任务分解 细化到可执行的粒度
例如：修复一个 rpc 接口，先列出代码修改点，测试点，合并到哪个分支，版本号修改，推到中央库，通知相关人员 - 多些单元测试
测试金字塔
- 测试驱动开发（TDD，Test Driven Development)
写代码之前，请先思考测试内容
- 开发任务分解
分解任务的关键在于”小”，具体小到什么程度呢？比如升级一次版本依赖，做一次变量改名，注意分解出来的任务实现时间最长不要超过半天。很多人代码漏洞百出，就是因为任务粒度太大，细节问题容易被忽略，因此将任务拆小，越小越好，即使开发被中断后面也可以接着开发。 - 行业最佳实践，基于主分支的模型
即大家都在同一个分支上开发。但为什么还有人要拉出一个分支进行开发呢？多半的原因是他写的代码太多了，改动量太大，很难很快地合到开发的主分支上来。 - 按照完整实现一个需求的顺序去安排分解出来的任务
需求开发时，很多人更习惯一个类一个类的写，但最好是按照一个需求、一个需求的过程走，这样，任务是可以随时停下来的。比如，同样是只有一半的时间，我至少交付了一个完整的需求，而按照分层的类写，结果是一个需求都没完成。 - 测试一定要写得简单
- 需求任务分解
尝试把需求拆开了再砍
1 用户故事作为我们讨论需求管理的基本单位 让用户故事分解得越小越好
2 INVEST 原则
3 需求的估算，比如，我们采用斐波那契数列，那这个最简单的用户故事就是基准点 1，其他用户故事要和它一一比较，如果一个用户故事比它复杂，那可以按照复杂程度给个估计值。所以，如果估算出一个用户故事在这个迭代周期不能完成，就可以考虑再进行拆分 - 需求排序
需求分解之后，最重要的是，排列需求的优先级。如何确定事情的重要程度，一种方式是找回丢失的上下文，如果我们自己无法判断上下文，就去引入外部更大的上下文，比如咨询更上级人员。
- 最小可行性产品（Minimum Viable Product，MVP）
首先，我们必须清楚一件事，我们要做的是验证一个想法的可行性，甚至不是为了开发一个软件，开发软件只是一种实现想法的路径，因此我们要找到最小路径。
1 调研，做产品文档，让销售给客户讲讲，看客户对这个想法的反映；
2 接下来进入产品设计阶段，该阶段验证的是用户是否接受这种产品设计，做出交互原型，根据用户使用情况不断反馈调整
3 最后进入开发阶段，找到最小可行路径，不是说一个模块做得有多完整，而是要看一条用户路径是否通畅。比如系统前期可能用不到的功能，就可以放在后期版本进行迭代，只需保证用户使用的部分保持完整即可，如何找到这条最小可行路径，答案就是需求分解 - 一名合格产品经理
多面对面沟通，少开会
开会前讨论前，产品先找到后端团队负责人，将每个需求与相关开发人员对应上，再把对应的需求具体内容发给相关开发人员，让开发人员先自己过一下，有问题就找产品讨论，或者产品在开发人员基本了解需求后，再一一找他们过需求。真正开会时，只做信息同步、需求优先级确认、时间安排，就无需在会上做需求评审。 - 高效站会
1 站会不超过 10 分钟
2 每个人同步内容只包括三件事：我昨天做了什么？我今天打算做什么？过程中碰到了什么问题，需要请求帮助
3 抛出问题，找到所需相关人，下来再单独讨论 - 构建个人、公司的技术雷达图
参考：构建一个技术雷达 - 复盘
1 回顾：做的好的 做的欠佳的 问题和建议 分析问题造成的原因（主观原因/客观原因） 给出行动项（可量化）
2 五个为什么 - 站在用户角度看自己的系统
- 尽早暴露问题（Fail Fast）
比如：针对透传参数的问题就应该在入口进行参数校验，尽早发现问题；配置中缺少重要参数时，不应该设置默认值进行兼容，而应该直接报错，抛出问题
原则：一个问题解决时间超过一个小时，还没思路的话，一定要去寻找帮助 - 文档输出-金字塔原理
- 做好自动化
你的日常工作是给别人打造自动化，但你自己的工作够自动化吗？
- 软件设计原则（SOLID）
1 单一职责原则
2 开放封闭原则
3 Liskov 替换原则
4 接口隔离原则
5 依赖倒置原则 - 用简单技术解决问题，直到问题变复杂
- 学会做领域驱动设计
在不熟悉领域设计的情况下，先用分模块的方式在一个工程内，让服务先演化一段时间，等到真的觉得某个模块可以”毕业”了，再进行微服务拆分 - 入职一家新公司，如何快速进入工作状态（第 38 章）
- 如何进行重构（第 39 章）
本文来自博客园，作者：这个杀手冷死了，转载请注明原文链接：https://www.cnblogs.com/pandacode/p/16564179.html
Original: https://www.cnblogs.com/pandacode/p/16564179.html
Author: 这个杀手冷死了
Title: “10X 程序员是如何思考的” 阅读总结
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/575876/
转载文章受原作者版权保护。转载请注明原作者出处！