如何做好一个需求

[TOC]
作为一名后台开发同学，做需求开发不可避免，无论是产品需求还是技术需求，需求虽然在变，但做事的方法是相同的，这里简单总结下从接到一个需求开始至需求上线的整个过程，以及其中需注意的点，避免后续踩坑

1. 明确需求

以产品需求举例，接到一个需求之后，首先要做的是搞明白这个需求，而不是一上来就是开始撸代码，这样很有可能导致最后上线的功能不符合产品预期

怎样明确一个需求？

1. 为什么做这件事，收益在哪里，让需求方来即产品经理讲，如果这个都讲不明白，这个需求可以直接拒掉，毕竟做了也没什么收益，这个道理在哪里都说得通
2. 明白1之后，产品一般都会提出自己的方案，但是这个方案是否合理 也需要我们开发自己来思考，不当工具人，有不合理的地方应该直接提出来和产品讨论
3. 需求预期上线时间以及验收标准

重点： 产品需求清晰后要追细节，避免一句话需求，凡是方案涉及到的细节点都需要在tapd or 企业微信中同步出来，避免后续返工

2. 开发

需求明确后，一般会开始排期，评估工作量，工作量拍脑门可不行，需方案明确后才能给出相对准确的排期

这里评估工时

• 工作点拆分的越细，一般评估的工时会更加准确
• 可以请有经验的同学帮忙评估，自己再留一定buff也可

拆分工作这里建议 写设计文档，之后排期也可以很明确的给出来，下边列下开发中要注意的点

• 设计文档

  • 需求描述，架构图，细节流程图，监控点，测试点等等，可以参考这里就不展开讲
  • 方案选型和涉及建议要有和业界或者公司内部部门的比较
  • 整体架构和方案指定后需评审，可以找组内小伙伴或者leader或者总监，都可以，查漏补缺

• 编码

  • 编码阶段注意写单元测试
  • 编码种碰到问题及时反馈出来讨论，技术问题或者产品逻辑问题都可以， 或者写入todo项也可

• 自测

  • 前提是单元测试已ok
  • 针对接口或者逻辑进行测试，后台开发一般需看日志来确认逻辑正常
  • 需测试到异常分支，这里最容易出问题

• 联调

  • 需求如果涉及到多方，需和上下游服务进行联调，此时更应该看服务端日志确认自己的逻辑正常才可以

• 监控

  • 需能看到异常or关键逻辑的监控是否正常

• debug

  • 需要有debug能力，比如可以针对单个用户染色，接入天机阁，可以很方便看到此用户日志，要不然排查问题成本太高

• 效果验收

  • 需让需求提出放在测试环境 验收，符合预期后进入下一步

• 性能验收

  • 压测当前服务，给出QPS，分位耗时等数据

• CR

  • 强烈建议 代码走读，前置查漏补缺，总比在线上发现问题好

这里要注意

• owner意识，自己承诺的时间点尽量要达到，如果有插入需求或者编码中碰到问题会影响进度，需及时反馈出来，而不能等到最后一天了才说没完成
• 追求效率，30min法则，如果一个问题自己google和思考30min还没解决的，及时反馈给导师or高T，再解决不了再向上反馈，不能死撑着
• 口头沟通基本无效，关键点需同步出来

此时开发侧基本工作已完成，下一步需在正式环境部署服务上线

3. 上线

• 资源评估

  • 建议前置，我厂资源申请还是比较麻烦的
  • 服务上线需要使用多少资源，cpu，mem，底层存储（redis，dcache）等等 需要前置评估出来
    • 这里根据之前的QPS数据，再结合预估的峰值流量 即可预估出需要部署多少节点
    • 这里要注意线上节点的负载不能过高，需要有一定冗余，线上负载建议在40-50%之间

• 资源申请

  • 一般是向运维同学申请，需说明需求背景，收益，资源推导公式 便于运维同学审批

• 资源部署

  • 部署在正式 和 灰度节点即可

• 压测

  • 之前压测使用的是自己构造的client，req和线上用户是不同的，这里建议使用线上旁路流量指定后端某一个节点进行压测，数据最为准确

• 发布流程

  • 灰度发布

    • 发布灰度节点，用户量比较小
    • 产品需在此环境验收功能是否正常
    • 开发需在此环境验收逻辑是否正常，通过日志确认

  • 旁路验证

    • 因之前机器资源是根据压测结果推导而来，假如结果不准 会导致线上服务异常，这里建议可以 先旁路线上流量至新服务上，对线上无影响，又可以验证服务性能，提前发现问题 提前解决

  • 正式发布

    • 这里建议使用 白名单+灰度百分比方式放量，风险最小
      • 产品开发先使用白名单体验，通过日志确认，功能正常之后再开始按百分比放量
      • 放量中注意观察服务负载和之前的监控等数据，有异常及时处理

这里多说两句，后台开发需对发布有敬畏之心，发布要灰度上线，逻辑都验证到才可以，切记不可发布完事就完事了，要对自己的发布负责，毕竟我们写的可不是玩具程序，是真的会影响上亿用户的体验的

4. 后续

1. 功能上线之后，还需关注上线之后效果如何，是否符合预期，可以和产品讨论是否有后续的优化点
2. 系统是否便于debug，如果不是 这里也是优化的点，毕竟开发同学有大部分时间都是在查case，这里效率一定要提高
3. 如何处理线上问题，建议看这篇 如何处理线上问题
4. 开发侧是否为了赶工期 有挖坑，比如有临时的解决方案，该填的坑也得填了
5. 总结。方案架构设计的对比，思考等等，持续总结才能提高自己的架构设计能力
6. 项目中使用的上下游组件是否了解其原理，比如使用 redis or kafka 是否真的了解了，都是可以学习的点