前言

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

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

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