前言

对我来说看完最大的收获，就是不要把自己设限于是一个开发人员，格局要打开！
  • 开发新需求前的四个思考原则（不能自答出来就问产品经理）

这个功能不做会怎么样？有没有什么替代方案？

  • 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 章）