日常开发方案设计指北
互联网公司管理研发流程，常常使用TAPD一类的敏捷工具。一个需求从提出到上线要经历至少七个流程：
- 1）需求评审：产品经理给出需求文档，邀请技术参与需求评审，目的是扫清需求疑点，排除无法实现的需求。
- 2）技术评审：技术人员内部评审需求，确定详细的技术方案。
- 3）开发排期：技术人员根据技术方案拆解任务，输出开发排期文档，并告知产品和测试，以便他们协调测试时间。
- 4）开发阶段：技术人员用代码实现需求，如果有需求疑点，继续找产品核实。在开发尾声，技术团队内部审查代码。
- 5）测试用例评审：测试人员根据需求文档拆分测试用例，并给出测试工作排期，确定需求最终上线日期。
- 6）测试阶段：测试人员根据测试用例分别在测试、预发布、灰度、生产环境测试。
- 7）产品验收：测试人员确认测试通过，邀请产品人员验收。
初级工程师往往做不好需求评审工作。要么被产品经理牵着鼻子走，让干什么就干什么；要么预估不到隐藏的工作量，在开发排期阶段给出不合理的排期，导致开发时间紧张，最后加班应付测试。
以下探讨的需求评审和技术方案设计等内容，都用电商的需求《优惠券管理平台》来举例说明。
需求标题：优惠券管理平台
需求背景：当前用户下单结算不支持任何优惠折扣活动，营销人员无法采用多样化的手段留存和获客。
需求内容：规划优惠券管理平台，运营人员申请营销预算，批量生成优惠券，赠送优惠券给不同画像的用户。购物车支持用户下单时使用优惠券。后台管理增加两大模块：1.营销预算管理；2.优惠券管理（配置优惠券模版、生成优惠券、赠送优惠券）。
详细设计：篇幅过长，略。
2.如何评审需求
2.1 三连追问
我们常常说研发人员也要有产品思维，并不是产品思维多么宝贵，而是没有产品思维，就不知道怎么拒绝产品经理的需求。面对任意一个需求，都要发起对产品经理的三连追问：
- 需求的价值是什么？
- 需求的后续规划是什么？
- 这个需求是必须的吗？
十个产品九个抄，很多产品经理的需求缺乏后续规划。他们没有完成产品的闭环思考，先抄袭别人的创意试试水。产品需求文档里面可能会出现前后逻辑矛盾，研发人员要抓住这些矛盾，给予重重的嘲讽，帮助他们改善工作。
2.2 需求拆分
如果一个需求的目的，无法用简短的话说清楚，就是不内聚的，要拆分需求后再分析。研发人员可以将需求拆分为3类：
- 必须实现：需求中价值最高的部分，上线后明显提升体验、提升获客能力或者增加客单量。
- 延迟实现：需求中价值低的部分，比如界面微调、表单校验等。在开发时间不充裕的情况下，尽可能延迟到下一版本中。
- 可以驳回：与本次需求没有关联、修复上个版本的BUG等等，考虑驳回。需求中参杂了没关联的功能，常常会增加沟通成本、代码审查的复杂度。
产品需要技术实现产品，研发需要产品展示价值，两者的利益是一致的。研发人员在质疑需求合理性时，措辞上要处在“为了产品更好”的基调上。如果需求被驳回，部分产品经理会抬出上一级领导压人，比如“这是李总要做的，你能怎么着”。如果需求确实荒谬，要上升到管理层去决定，否则产品经理会玩成惯性。
3.如何设计技术方案
拿到一个需求，尤其是周期长、功能多的需求，要考虑多个方面来设计技术方案，做到低成本、高性能、可维护。
3.1 适应变化
没有一劳永逸的方案，适应一定阶段的变化即可。要与产品经理沟通，基本确定未来几个月的变与不变。在《优惠券管理平台》里面，优惠券的产生、使用、核销三个状态的流转是确定的，而使用规则可能会变化，一开始可能随便用，后来演变成按商品分类、品牌划分。针对变的部分要考虑可扩展性，比如数据库字段类型采用JSON，或者设计规则扩展表。
3.2 避免耦合
以业务领域为界限，规划每个微服务工程的职责。在《优惠券管理平台》里面，优惠券是新业务，至少需要一个新微服务。营销预算与优惠券不是强关联的，未来可能赠送礼品卡或者实物纪念品，营销预算的代码不能写在优惠券的微服务里面。
3.3 估算资源消耗
根据接口访问次数或者前端埋点统计，预估业务产生的数据量，估值越具体越好。例如: 双十一活动中，预估发放优惠券100万个，购物车结算页面查询优惠券接口达到1000QPS。根据这些结论，才能更好的规划数据库表的分片设计、查询接口的性能设计。
3.4 安全问题
- 1）数据安全
避免泄漏用户数据，将敏感信息如手机号、银行卡明文显示在页面中；暴露的链接是否包含敏感参数，比如营销短信内容的推广链接包含用户ID。
- 2）接口安全
给前端使用的接口是否防刷；访问外部接口要设置访问超时时间。
3.5 输出文档
编写技术方案文档有两个作用，一是用于技术评审，二是方便接盘侠参考。文档至少包括6个要点：
- 1）详细需求：把产品经理的需求文档搬过来。
- 2）系统流程图：通常是业务流程图、系统泳道图、微服务调用图。
- 3）数据表设计：涉及到新表的设计、旧表的改动。
- 4）改造点清单：所有要改动的旧模块的Class等等。
- 5）灰度计划：如果需求只针对符合规则的部分用户展现新的产品流程，必须注明灰度计划。
- 6）业务配置项：通过动态配置项管理的业务规则。