研发流程总结

关于bug

产品需求，技术设计，编码自测，测试验证，上线运行。

产品需求:判断需求是否有问题，

1. 可以通过梳理数据维度，画出er图来判断是否合理。并按照数据维度来判断每项功能是否合理。

2. 相当一部分功能都是围绕某一项数据来做crud。其中除查询外推荐可以查询批量，插入、更新、删除等均为修改数据操作，此类接口要格外谨慎。数据库里脏数据的来源。推荐先做好setnx确保数据在短时间只请求一次，防止插入或者更新带来的cas问题。

产品需求的问题可以直接反馈给产品进行修改打磨。研发花费代价最低。

技术设计方案:

几乎所有的需求都可以归结为增删改查。前面的产品需求也提到过。在需求评审阶段可以思考如下的细节点，若有问题也可以及早反馈给产品。

查询:则考虑查空边界，分页查的深分页，查询维度。

插入:插入一个已存在的数据处理需要upsert吗，数据来源是怎样的是人手动插入还是系统自动插入，这个对于判断业务流量，系统数据延迟有很重要的参考。

更新:最需要关注更新条件，推荐更新为最细粒度更新。更新后的数据是否为空，需要和产品确认防止另类删除。

删除:删除最关注的还是删除条件。删除也需要考虑最细粒度。原则上没不应该有真正删除，最好有一个delete字段判断是否删除。若被删除则delete字段被赋值为数据库的主键id，理由若有uniquekey，删除后更新delete字段，再插一条就会有冲突，推荐uniquekey和delete字段合并成一个新的uniquekey。

到目前为止，修改的操作只剩下插入和更新，这两个操作都存在CAS问题。对于插入来说没有什么业务会存完完全全一模一样的数据，即使业务是这样的，从技术角度一定有什么方式可以做好区分。也就是对于插入来讲，都需要先查再插入。其实严格的更新操作也是一样需要先查再更新。那么插入和变成了upsert。通常做法需要使用setnx来让请求是顺序的，但考虑到成本等因素还是需要进一步分类讨论。

若请求是以userId维度或者更细粒度的维度请求的，且能从业务角度明确短时间（比如1s内）不会出现两个要插入或者更新请的内容不同的请求，推荐建表不要用userID为主键或者uniquekey，更推荐使用二级索引，一方面防止丢失有价值的冲突数据，像订单类数据需要全部保留好，另一方面防止潜在极端死锁可能。像一些web后台，仅仅是少数人操作，几乎不会出现一个用户会短时间有竞争的可能。那么直接upsert其实也可以接受。一般业务还是更推荐需要setnx做幂等，毕竟此种方式是最为严格，防止脏数据的出现。

技术方案出问题尽量在技术方案评审阶段完善。技术方案文档的原则需要详尽，不是一次性就可以完成是一直需要持续迭代。

v0版:草稿阶段，先构思出自己的想法，并和产品沟通，一方面正确理解需求，若需求无法满足，需要告知产品无法满足的原因，建议满足不了先和组内leader和资深研发讨论一下，若确认原因是充分的，然后告知产品不能实现的原因。目标:技术和产品达成共识。

v1版:在v0的基础上，进一步完善。要注意以下几点:

项目背景:这个项目是要做什么？目标是啥？都解决了哪些关键性的问题。一般来说需求总体分产品需求和技术需求，产品需求在需求文档的开头会着重介绍，在需求评审会产品开始会讲。那么对于技术来讲，项目背景就可以直接写需求文档附上链接。若有自己的理解，可以顺带在技术方案项目背景里介绍清楚。若为技术需求，则需要着重细致介绍。若篇幅过长，可以另起一篇技术需求文档来介绍技术改造目标。

方案架构:往往需要一个流程图来介绍。并辅以文字解释。方案架构还需要二级标题，详细讲每块的实现逻辑，甚至会涉及到对应的表创建等等。对于细节表述需要单列，而一些未来上线需要做的细致事（表创建，计划任务脚本上线，各种配置改动等等）需要单列上线计划。但具体事项逻辑是要放到对应的二级标题甚至三级标题里。

技术预研:假如方案要涉及到某个之前没有接触过的存储，需要自己0-1进行建设，则需要预研时间，这个需要和leader，资深研发还有产品等明确需要调研，原则上不应该直接给排期。在不清楚要依赖的技术是否真正满足技术方案需求，则给出的排期根本不准确，只能给出一个大概的预研排期，原则上不应该着急给出具体排期。给出一个误差极大的排期是不负责任的。若本次方案不涉及技术预研，则这列不需要单独写出。

任务拆分:将技术方案里的细节按照人天单位用表格形式列出来。任务要详尽，工作量对应的人天要合理，不能过度夸张，比如改个配置要3天人，肯定不合适。也不能将很大的整体方案直接写成5人天，这样不够细致。排期出具要科学评估，需要明确的事情做支撑，这样即使有人质疑也有理有据来回应。一些借鉴的原则:1人天对应6个小时而非8小时，理由:一般研发不仅仅是进行项目开发，还可能会有临时的会议，线上问题需要关注，某个同学需要oncall，甚至可能是某天生病身体不舒需要请假一天等等。但更多的耗时其实来自技术方案有些细节点可能没有考虑全。比如实际是有10处地方需要注意，但是只考虑了8处等等，从这一点让研发细化方案的目的就是尽可能减少未考虑的细节。若有的研发同学处于白天都有别的事占据，晚上才能编码状态，可以按照4小时做为人天来评估。

接口文档:若需要出具文档，需要根据设计写出接口，并给出链接地址，发给前端看看。

上线计划:将技术方案里涉及到的表，配置，计划任务等等需要列出来以及上线的次序等，确认是否合理。

v1.1版，在v0的基础上已经明确好所有需要做的事:包括:

    1.技术预研所涉及的方方面面。

    2.相关依赖系统的对接人，已经明确使用场景，QPS，等等。这个在上线计划也需要进一步提及。

此时准备发起需求评审，若评审通过，则按照技术方案的排期来。若有问题，则根据实际情况修改技术方案。此时有问题改动成本还不是很大。只需要修改方案即可。

v2版本是研发阶段要迭代的事情。

编码自测阶段:

依据详尽的v1版文档进行编码测试。

技术方案文档此阶段要进化到v2版。重点会有如下优化:

1.测试的测试用例评审，需要进一步完善实现细节，这个也是以6小时为一人天的原因之一。

2.编码是最细节的实现，之前的细节很难照顾到某个琐碎的细节，万一还有别的问题或者调测发现不通等情况需要解决并写到文档里解决方案。特别是能带到线上的情况，有必要的话需要加一项:线上问题处理方式。

3.发现了更好的方案，若新方案可以减少工作量，则需要修改方案，且继续编码，多余时间加强自测。为何不直接报给产品可以提前排，一方面是自己往往没有处理完所有细节，可能另一个细节需要花更多的时间。反复和产品确认修改排期不是一个明智的决定，这样容易造成产品和研发之间的不信任感。还不如用来确保质量，增强产品和研发信任感。若新方案需要加时间，先看加多久，时间不够看看是否可拆分加人，或者考虑新方案是否值得全部实现才能满足需求，看看产品是否可以延排期。

4.需求还可能漏掉一些分支，比如Switch的default分支处理。这个也需要和产品沟通确认以及可能影响到方案的改动。

5.技术调测发现额外的问题等等均可能完善到技术方案v2版。

技术设计的细节处理要考虑一个度，如果时间可以建议越细致越好，这样细节充分能明确好排期，防止研发延误排期，当然代价可能技术方案时间可能和编码时间差不多。造成后续同事工作的调整造成的不便。若时间比较紧，建议细节设计和代码实现考虑2小时的误差，再多就是自己加班。

此时如果出问题多半是代码的小改动，或者加班加人容易弥补大问题。把代码改好就行。

联调阶段

一般需要提前约好具体时间。

测试验证

越到后期改动成本越大。